One document matched: draft-baker-ietf-core-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="4"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-baker-ietf-core-05" ipr="trust200902">
<front>
<title abbrev="Internet Protocols for the Smart Grid">Internet Protocols
for the Smart Grid</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date year="2010" />
<area>General</area>
<workgroup></workgroup>
<abstract>
<t>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.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<note title="Requirements">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</note>
-->
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section title="Introduction">
<t>In the discussion of the Smart Grid, a question has arisen as to how
best to "profile" the Internet Protocol Suite are. In this note, I will
attempt to identify the structure of the Internet Protocol Suite and the
key protocols that should be considered as critical in integrating Smart
Grid devices into an IP-based infrastructure. In many cases, the
protocols are options - one might choose, for example, TCP, SCTP, DCCP,
or some other transport, or use expand upon UDP, building the transport
into the application itself. In the Transport layer, therefore, one is
not limited to exactly one of those, nor is one required to implement
them all. One should, however, pick the right one for the purpose one
intends. This kind of discussion will be had at every layer.</t>
<t>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
Grid, these end systems will be various devices such as power meters,
sensors and actuators. These end systems can leverage infrastructure
built on networking components using the IP Protocol Suite, which have
well-proven implementations and deployments in the Internet. That said,
it also goes on to mention network-only technology including routing
protocols and circuit switching models, which may be useful in networks
supporting the Smart Grid.</t>
<t>For its own purposes, the IETF has written several documents that
describe its expectations regarding implementations of the Internet
Protocol Suite. These include: <list style="symbols">
<t><xref target="RFC1122">Requirements for Internet Hosts -
Communication Layers</xref>,</t>
<t><xref target="RFC1123">Requirements for Internet Hosts -
Application and Support</xref>,</t>
<t><xref target="RFC1812">Requirements for IP Version 4
Routers</xref>, and</t>
<t><xref target="RFC4294">IPv6 Node Requirements</xref>,</t>
</list></t>
<t>At this writing, RFC 4294 is in the process of being updated, in
<xref target="I-D.ietf-6man-node-req-bis"></xref>.</t>
<t>This document will read like an annotated list of RFCs. That is
because that is what it is.</t>
</section>
<section anchor="suite" title="The Internet Protocol Suite">
<t>Before listing a list of protocols, it would be well to lay out how
they relate to each other. In this section, we will discuss the layered
architecture of the Internet Protocol Suite and the jobs of the various
layers and their protocols.</t>
<section anchor="architecture" title="Internet Protocol Layers">
<t>The Internet Architecture uses the definitions and language of the
ISO Open System Interconnect Reference Model, as shown in <xref
target="iso-osi"></xref>. It actually predates that model, and as a
result uses some different words - an "end system" is generally called
a "host", and an "intermediate system" is more generally called an
"internet gateway" or "router". But the fundamental concepts are
essentially the same.</t>
<figure anchor="iso-osi" title="The ISO OSI Reference Model">
<artwork align="center"><![CDATA[
+--------------------+
| Application Layer |
+--------------------+
| Presentation Layer |
+--------------------+
| Session Layer |
+--------------------+
| Transport layer |
+--------------------+
| Network Layer |
+--------------------+
| Data Link Layer |
+--------------------+
| Physical Layer |
+--------------------+
]]></artwork>
</figure>
<t>The structure of the Internet reference Model looks something like
<xref target="irm"></xref>.</t>
<figure anchor="irm" title="The Internet Reference Model">
<artwork align="center"><![CDATA[
+---------------------------------+
|Application |
| +---------------------------+ |
| | Application Protocol | |
| +----------+----------------+ |
| | Encoding | Session Control| |
| +----------+----------------+ |
+---------------------------------+
|Transport |
| +---------------------------+ |
| | Transport layer | |
| +---------------------------+ |
+---------------------------------+
|Network |
| +---------------------------+ |
| | Internet Protocol | |
| +---------------------------+ |
| | Lower network layers | |
| +---------------------------+ |
+---------------------------------+
|Media layers |
| +---------------------------+ |
| | Data Link Layer | |
| +---------------------------+ |
| | Physical Layer | |
| +---------------------------+ |
+---------------------------------+
]]></artwork>
</figure>
<section title="Application">
<t>In implementation, the Application, Presentation, and Session
layers are generally compressed into a single entity, which the IETF
calls "the application". The SNMP protocol, for example, describes
an application (a management application or a client that it
communicates with) that encodes its data in a profile of ASN.1 (a
presentation layer) and engages in a session to manage a network
element. In the Internet, therefore, the distinction between these
layers exists but is not generally highlighted. Note, in <xref
target="irm"></xref>, that these are not necessarily cleanly
layered: the fact that an application protocol encodes its data in
some way and that it manages sessions in some way doesn't imply a
hierarchy between those processes. Rather, the application views
encoding, session management, and a variety of other services as a
tool set that it uses while doing its work.</t>
</section>
<section title="Transport">
<t>The term "transport" is perhaps among the most confusing words in
the communication architecture, because people with various
backgrounds use it to refer to "the layer below that which I am
interested in, which gets my data to my peer". In these contexts,
optical fiber and other physical layers, the Internet Protocol or
other networked protocols, and in some cases application layer
protocols like HTTP are referred to as "the transport".</t>
<t>In the Internet context, the "transport" is the lowest layer that
travels end-to-end unmodified, and is responsible for end-to-end
data delivery services. At minimum these include the ability to
multiplex several applications on one IP address, and may also
include the delivery of data (either as a stream of messages or a
stream of bytes) in a stated sequence with stated expectations
regarding delivery rate and loss. TCP, for example, will reduce rate
to avoid loss, while DCCP accepts some level of loss if necessary to
maintain timeliness.</t>
</section>
<section title="Network">
<t>The network layer is nominally that which identifies a remote
destination and gets data to it. In connection-oriented networking,
such as MPLS or ATM, a path (one of many "little tubes") is set up
once, and data is delivered through it. In connectionless
("datagram") networks, which include Ethernet and IP among others,
each datagram contains the addresses of both the source and
destination devices, and the network is responsible to deliver
it.</t>
<section title="Internet Protocol">
<t>IPv4 and IPv6, each of which is called the Internet Protocol,
are connectionless ("datagram") architectures. They are designed
as common elements that interconnect network elements across a
network of lower layer networks. In addition to the basic service
of identifying a datagram's source and destination, they offer
services to fragment and reassemble datagrams when necessary,
assist in diagnosis of network failures, and carry additional
information necessary in special cases.</t>
<t>The Internet Layer provides a uniform network abstraction or
virtual network that hides the differences between different
network technologies. This is the layer that allows diverse
networks such as Ethernet, 802.15.4, etc. to be combined into a
uniform IP network. New network technologies can be introduced
into the IP Protocol Suite by defining how IP is carried over
those technologies, leaving the other layers of the IP Protocol
Suite and applications that use those protocol unchanged.</t>
</section>
<section title="Lower layer networks">
<t>The network layer is recursively subdivided as needed. For
various reasons, IP may be carried in virtual private networks
across more public networks using tunneling technologies like
IP-in-IP or GRE, traffic engineered in circuit networks such as
MPLS, GMPLS, or ATM, and distributed across local wireless (IEEE
802.11, 802.15.4, or 802.16) and switched Ethernet (IEEE
802.3).</t>
</section>
</section>
<section title="Media layers: Physical and Link">
<t>At the lowest layer of the architecture, we encode digital data
in messages onto appropriate physical media. While the IETF
specifies algorithms for carrying IPv4 and IPv6 on such media, it
rarely actually defines the media - it happily uses specifications
from IEEE, ITU, and other sources.</t>
</section>
</section>
<section anchor="security-issues" title="Security issues">
<t>It is popular to complain about the security of the Internet; that
said, solutions exist but are often left unused. As with automobile
seat belts, they are of more value when actively used. Security
designs attempt to mitigate a set of known threats at a specified
cost; addressing security issues 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.</t>
<section title="Physical security ">
<t>At the physical and data link layers, threats involve physical
attacks on the network - the effects of backhoes, deterioration of
physical media, and various kinds of environmental noise.
Radio-based networks are subject to signal fade due to distance,
interference, and environmental factors; it is widely noted 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 time
deployed because it was believed to be untappable; we have since
learned to tap it by bending the fiber and collecting incidental
light, and we have learned about backhoes. So now some installations
encase fiber optic cable in a pressurized sheath, both to quickly
identify the location of a cut and to make it more difficult to
tap.</t>
<t>While there are protocol behaviors that can detect certain
classes of physical faults, such as keep-alive exchanges, physical
security is generally not a protocol problem.</t>
</section>
<section title="Session identification">
<t>At the transport and application layers, and in lower layer
networks where dynamic connectivity like ATM SVCs or "dial"
connectivity is in use, there tend to be several different classes
of authentication/authorization requirements. One must <list
style="numbers">
<t>Verify that the peers one exchanges data with are appropriate
partners; this generally means knowing "who" they are and that
they have a "need to know" or are trusted sources.</t>
<t>Verify that information that appears to be from a trusted
peer is in fact from that peer.</t>
<t>Validate the content of the data exchanged; it must conform
to the rules of the exchange.</t>
<t>Defend the channel against denial of service attacks.</t>
<t>Ensure the integrity of the information transported to defend
against modification attacks.</t>
</list></t>
<t>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 the source of the information and to have proof of its
validity. Three examples suffice to illustrate the challenges.</t>
<t>One common attack is to bombard a transport session (an
application's channel) with reset messages. If the attacker is
lucky, he might cause the session to fail. Including information in
the transport header or a related protocol like IPsec or TLS that
identifies the right messages and facilitates speedy discard of the
rest can mitigate this.</t>
<t>Another common attack involves unauthorized communication with a
router or a service. For example, an unauthorized party might try to
join the routing system. One wants the ISP's router, before
accepting routing information from a new peer, to<list
style="symbols">
<t>demand identification from the new peer,</t>
<t>verify that the peer is in fact who it claims to be, and</t>
<t>verify that it is authorized to carry on the exchange.</t>
</list></t>
<t>More generally, in securing the channel, one wants to verify that
messages putatively received from a peer were in fact received from
the peer, and given that they are, to only carry on transactions
with peers that one trusts. This is analogous to how one responds to
a salesman at the front door - one asks who the salesman represents,
seeks a credential as proof, and then asks one self whether one
wants to deal with that company. Only if all indications are
positive does one carry on a transaction.</t>
<t>Unfortunately, even trusted peers can be the purveyors of
incorrect or malicious content; having secured the channel, one also
wants to secure the information exchanged through the channel. In
electronic mail and other database exchanges, it may be necessary to
be able to verify the identity of the sender and the correctness of
the content long after the information exchange has occurred - for
example, if a contract is exchanged that is secured by digital
signatures, one will wish to be able to verify those signatures at
least throughout the lifetime of the contract, and probably a long
time after that.</t>
<t>The third "A" in "AAA" is Accounting. This service is especially
important for Internet Service Providers; the related service of
auditing is important for enterprises. RADIUS and DIAMETER are
commonly used to realize these services.</t>
</section>
<section title="Confidentiality">
<t>At several layers, there is a question of confidentiality. If one
is putting one's credit card in a transaction, one wants application
layer privacy, which might be supplied by an encrypting application
or transport layer protocol. If one is trying to hide one's network
structure, one might additionally want to encrypt the network layer
header.</t>
</section>
</section>
<section anchor="infra" title="Network Infrastructure">
<t>While these are not critical to the design of a specific system,
they are important to running a network. We therefore bring them
up.</t>
<section anchor="dns" title="Domain Name System (DNS)">
<t>While not critical to running a network, certain functions are
made a lot easier if numeric addresses can be replaced with mnemonic
names. This facilitates renumbering of networks, which happens, and
generally improves the manageability and serviceability of the
network. DNS has a set of security extensions called DNSSEC, which
can be used to provide strong cryptographic authentication to that
protocol.</t>
</section>
<section title="Network Management Issues">
<t>Network management has proven to be a difficult problem; there
are many solutions, and each has proponents with solid arguments for
their viewpoint. In the IETF, we have two major network management
solutions for device operation: SNMP, which is ASN.1-encoded and is
primarily used for monitoring of system variables in a polled
architecture, and NetConf, which is XML-encoded and primarily used
for device configuration.</t>
<t>Another aspect of network management is the initial provisioning
and configuration of hosts. Address assignment and other
configuration is discussed in <xref target="dhcp"></xref>. Smart
Grid deployments will require additional identity authentication and
authorization as well as other provisioning and configuration that
may not be within the scope of DHCP and Neighbor Discovery. While
the IP Protocol Suite does not have specific solutions for secure
provisioning and configuration, these problems have been solved
using IP protocols in specifications such as <xref
target="SP-MULPIv3.0">DOCSIS 3.0</xref>.</t>
</section>
</section>
</section>
<section anchor="protocols" title="Specific protocols">
<t>In this section, having briefly laid out the architecture and some of
the problems that the architecture tries to address, we introduce
specific protocols that might be appropriate to various use cases. In
each place, the options are in the protocols used - one wants to select
the right privacy, AAA, transport, and network solutions in each
case.</t>
<section anchor="security-solutions" title="Security solutions">
<t>As noted, a key consideration in security solutions is a good
threat analysis coupled with appropriate mitigations at each
layer.</t>
<section title="Session identification, authentication, authorization, and accounting">
<t>In the Internet Protocol Suite there are several approaches to
AAA issues; generally, one chooses one of them for a purpose. As
they have different attack surfaces and protection domains, they
require some thought in application. Two important ones are the IP
Security Architecture, which protects IP datagrams, and Transport
Layer Security, which protects the information that the Transport
delivers.</t>
</section>
<section title="IP Security Architecture (IPsec)">
<t>The <xref target="RFC4301">Security Architecture for the Internet
Protocol</xref> is a set of control and data protocols that are
implemented between IPv4 and its Transport layer, or in IPv6's
Security extension header. It allows transport layer sessions (which
underlie applications) to communicate in a way that is designed to
prevent eavesdropping, tampering, or message forgery. The
architecture is spelled out in a number of additional specifications
for specific components: the <xref target="RFC4302">IP
Authentication Header (AH)</xref> <xref
target="RFC4303">Encapsulating Security Payload (ESP)</xref>, <xref
target="RFC4306">Internet Key Exchange (IKEv2) </xref>, <xref
target="RFC4307">Cryptographic Algorithms</xref>, <xref
target="RFC4835">Cryptographic Algorithm Implementation Requirements
for ESP and AH</xref>, and the use of <xref
target="RFC4309">Advanced Encryption Standard (AES) </xref>.</t>
<t>In the transport mode, IPsec ESP encrypts the transport layer and
the application data. In the tunnel mode, which is frequently used
for Virtual Private Networks, one also encrypts the Internet
Protocol, and encapsulates the encrypted data inside a second IP
header directed to the intended decryptor.</t>
</section>
<section title="Transport Layer Security (TLS)">
<t><xref target="RFC5246">Transport Layer Security</xref> and <xref
target="RFC4347">Datagram Transport Layer Security</xref><xref
target="I-D.ietf-tls-rfc4347-bis"></xref> are mechanisms that travel
within the transport layer PDU, meaning that they readily traverse
network address translators and secure the information exchanges
without securing the datagrams exchanged or the transport layer
itself. Each allows client/server applications to communicate in a
way that is designed to prevent eavesdropping, tampering, or message
forgery.</t>
</section>
<section title="Secure/Multipurpose Internet Mail Extensions (S/MIME)">
<t>The <xref target="RFC2045">S/MIME</xref> <xref
target="RFC2046"></xref> <xref target="RFC2047"></xref> <xref
target="RFC4289"></xref> <xref target="RFC2049"></xref> <xref
target="RFC3850"></xref> <xref target="RFC3851"></xref> <xref
target="RFC4262"></xref> specification was originally specified 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
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
be exchanged, by any means, and has become one of the most common
ways to secure an object.</t>
<t>Other approaches also exist, such as the use of digital
signatures on XML-encoded files, as jointly standardized by W3C and
the IETF <xref target="RFC3275"></xref>.</t>
</section>
</section>
<section title="Network Layer">
<t>Here we mention both IPv4 and IPv6. The reader is warned: IPv4 is
running out of address space, and IPv6 has positive reasons that one
might choose it apart from the IPv6 space such as the address
autoconfiguration facility and its ability to support an arbitrarily
large number of hosts in a subnet. As such, the IETF recommends that
one always choose IPv6 support, and additionally choose IPv4 support
in the near term.</t>
<section anchor="ipv4" title="Internet Protocol Version 4">
<t><xref target="RFC0791">IPv4</xref>, with the <xref
target="RFC0792">Internet Control Message Protocol</xref>,
constitutes the traditional protocol implemented throughout the
Internet. IPv4 provides for transmission of datagrams from source to
destination hosts, which are identified by fixed length
addresses.</t>
<t>IPv4 also provides for fragmentation and reassembly of long
datagrams, if necessary, for transmission through "small packet"
networks. ICMP, which is a separate protocol implemented along with
IPv4, enables the network to report errors and other issues to hosts
that originate problematic datagrams.</t>
<t>IPv4 originally supported an experimental type of service field
that identified eight levels of operational precedence styled after
the requirements of military telephony, plus three and later four
bit flags that IS-IS and OSPF interpreted as affecting traffic
routing for datagrams requiring lower delay or higher throughput.
These turned out to be less useful than the designers had hoped.
They were replaced by the <xref target="RFC2474">Differentiated
Services Architecture</xref><xref target="RFC2475"></xref>, which
contains a six bit code point used to select an algorithm (a
"per-hop behavior") to be applied to the datagram.</t>
<section title="IPv4 Address Allocation and Assignment">
<t>IPv4 addresses are administratively assigned, usually using
automated methods, and assigned using the <xref
target="RFC2131">Dynamic Host Configuration Protocol
(DHCP)</xref>. On most interface types, neighboring equipment
identify each other's addresses using <xref
target="RFC0826">Address Resolution Protocol (ARP)</xref>.</t>
</section>
<section title="IPv4 Unicast Routing">
<t>Routing for the IPv4 Internet is done by routing applications
that exchange connectivity information and build semi-static
destination routing databases. If a datagram is directed to a
given destination address, the address is looked up in the routing
database, and the most specific ("longest") prefix found that
contains it is used to identify the next hop router, or the end
system it will be delivered to. This is not generally implemented
on hosts, although it can be; generally, a host sends datagrams to
a router on its local network, and the router carries out the
intent.</t>
<t>IETF specified routing protocols include <xref
target="RFC2453">RIP Version 2</xref>, <xref target="RFC1195">OSI
IS-IS for IPv4</xref>, <xref target="RFC2328">OSPF Version
2</xref>, and <xref target="RFC4271">BGP-4</xref>. Active research
exists in mobile ad hoc routing and other routing paradigms; these
result in new protocols and modified forwarding paradigms.</t>
</section>
<section anchor="Multicast"
title="IPv4 Multicast Forwarding and Routing">
<t>IPv4 was originally specified as a unicast (point to point)
protocol, and was extended to support multicast in <xref
target="RFC1112"></xref>. This uses the <xref
target="RFC3376">Internet Group Management Protocol</xref><xref
target="RFC4604"></xref> to enable applications to join multicast
groups, and for most applications uses <xref
target="RFC4607">Source-Specific Multicast</xref> for routing and
delivery of multicast messages.</t>
<t>An experiment carried out in IPv4 that is not core to the
architecture but may be of interest in the Smart Grid is the
development of so-called "Reliable Multicast". This is "so-called"
because it is not "reliable" in the strict sense of the word - it
is perhaps better described as "enhanced reliability". A best
effort network by definition can lose traffic, duplicate it, or
reorder it, something as true for multicast as for unicast.
Research in "Reliable Multicast" technology intends to improve the
probability of delivery of multicast traffic.</t>
<t>In that research, the IETF imposed <xref
target="RFC2357">guidelines</xref> on the research community
regarding what was desirable. Important results from that research
include a number of papers and several proprietary protocols
including some that have been used in support of business
operations. RFCs in the area include <xref target="RFC3453"> The
Use of Forward Error Correction (FEC) in Reliable Multicast
</xref>, the <xref target="RFC3940"> Negative-acknowledgment
(NACK)-Oriented Reliable Multicast (NORM) Protocol </xref>, and
the <xref target="RFC4410"> Selectively Reliable Multicast
Protocol (SRMP) </xref>. These are considered experimental.</t>
</section>
</section>
<section anchor="ipv6" title="Internet Protocol Version 6">
<t><xref target="RFC2460">IPv6</xref>, with the <xref
target="RFC4443">Internet Control Message Protocol "v6"</xref>,
constitutes the next generation protocol for the Internet. IPv6
provides for transmission of datagrams from source to destination
hosts, which are identified by fixed length addresses.</t>
<t>IPv6 also provides for fragmentation and reassembly of long
datagrams by the originating host, if necessary, for transmission
through "small packet" networks. ICMPv6, which is a separate
protocol implemented along with IPv6, enables the network to report
errors and other issues to hosts that originate problematic
datagrams.</t>
<t>IPv6 adopted the <xref target="RFC2474">Differentiated Services
Architecture</xref><xref target="RFC2475"></xref>, which contains a
six bit code point used to select an algorithm (a "per-hop
behavior") to be applied to the datagram.</t>
<t>The <xref target="RFC4919">IPv6 over Low-Power Wireless Personal
Area Networks</xref> RFC and the <xref
target="I-D.ietf-6lowpan-hc">Compression Format for IPv6 Datagrams
in 6LoWPAN Networks</xref> 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.</t>
<section title="IPv6 Address Allocation and Assignment">
<t>An <xref target="RFC4291">IPv6 Address</xref> may be
administratively assigned using <xref
target="RFC3315">DHCPv6</xref> in a manner similar to the way IPv4
addresses are, but may also be autoconfigured, facilitating
network management. Autoconfiguration procedures are defined in
<xref target="RFC4862"></xref> and <xref target="RFC4941"></xref>.
IPv6 neighbors identify each other's addresses using either <xref
target="RFC4861">Neighbor Discovery (ND)</xref> or <xref
target="RFC3971">SEcure Neighbor Discovery (SEND)</xref>.</t>
</section>
<section title="IPv6 Routing">
<t>Routing for the IPv6 Internet is done by routing applications
that exchange connectivity information and build semi-static
destination routing databases. If a datagram is directed to a
given destination address, the address is looked up in the routing
database, and the most specific ("longest") prefix found that
contains it is used to identify the next hop router, or the end
system it will be delivered to. This is not generally implemented
on hosts, although it can be; generally, a host sends datagrams to
a router on its local network, and the router carries out the
intent.</t>
<t>IETF specified routing protocols include <xref
target="RFC2080">RIP for IPv6</xref>, <xref target="RFC5308">IS-IS
for IPv6</xref>, <xref target="RFC5340">OSPF for IPv6</xref>, and
<xref target="RFC2545">BGP-4 for IPv6</xref>. Active research
exists in mobile ad hoc routing, routing in low power networks
(sensors and smart grids) and other routing paradigms; these
result in new protocols and modified forwarding paradigms.</t>
</section>
<section title="IPv6 Multicast Forwarding and Routing">
<t>From its initial design, IPv6 has specified both unicast and
multicast datagram exchange. This uses the <xref
target="RFC2710">Multicast Listener Discovery Protocol
(MLDv2)</xref> <xref target="RFC3590"></xref> <xref
target="RFC3810"></xref> <xref target="RFC4604"></xref> to enable
applications to join multicast groups, and for most applications
uses <xref target="RFC4607">Source-Specific Multicast</xref> for
routing and delivery of multicast messages.</t>
<t>The mechanisms experimentally developed for reliable multicast
in IPv4, discussed in <xref target="Multicast"></xref>, can be
used in IPv6 as well.</t>
</section>
</section>
<section title="Adaptation to lower layer networks and link layer protocols">
<t>In general, the layered architecture enables the Internet
Protocol Suite to run over any appropriate layer 2 architecture;
with tongue in cheek, specifications have been written and
demonstrated to work for the carriage of <xref target="RFC1149">IP
by Carrier Pigeon</xref><xref target="RFC2549"></xref> (perhaps the
most common carrier known to man) and on <xref
target="Chapman">barbed wire</xref>. The ability to change the link
or physical layer without having to rethink the network layer,
transports, or applications has been a great benefit in the
Internet.</t>
<t>Examples of link layer adaptation technology include: <list
style="hanging">
<t hangText="Ethernet/IEEE 802.3:">IPv4 has run on each link
layer environment that uses the Ethernet header (which is to say
10 and 100 MBPS wired Ethernet, 1 and 10 GBPS wired Ethernet,
and the various versions of IEEE 802.11) using <xref
target="RFC0894"></xref>. IPv6 does the same using <xref
target="RFC2464"></xref>.</t>
<t hangText="PPP:">The IETF has defined a serial line protocol,
the <xref target="RFC1661">Point-to-Point Protocol (PPP)</xref>,
that uses HDLC (bit-synchronous or byte synchronous) framing.
The IPv4 adaptation specification is <xref
target="RFC1332"></xref>, and the IPv6 adaptation specification
is <xref target="RFC5072"></xref>. Current use of this protocol
is in traditional serial lines, authentication exchanges in DSL
networks using <xref target="RFC2516">PPP Over Ethernet
(PPPoE)</xref>, and in the Digital Signaling Hierarchy
(generally referred to as Packet-on-SONET/SDH) using <xref
target="RFC2615">PPP over SONET/SDH</xref>.</t>
<t hangText="IEEE 802.15.4:">The adaptation specification for
IPv6 transmission over IEEE 802.15.4 Networks is <xref
target="RFC4944"></xref>.</t>
</list></t>
<t>Numerous other adaptation specifications exist, including ATM,
Frame Relay, X.25, other standardized and proprietary LAN
technologies, and others.</t>
</section>
</section>
<section title="Transport Layer">
<t>In this we list several transports: UDP, TCP, SCTP, and DCCP. Of
these, UDP and TCP are best known and most widely used, due to
history. SCTP and DCCP were built for specific purposes more recently
and bear consideration at least for those purposes.</t>
<t>Note that if it is appropriate, other transports can also be built.
This is largely a question of requirements.</t>
<section title="User Datagram Protocol (UDP)">
<t>The <xref target="RFC0768">User Datagram Protocol</xref> and the
<xref target="RFC3828">Lightweight User Datagram Protocol</xref> are
properly not "transport" protocols in the sense of "a set of rules
governing the exchange or transmission of data electronically
between devices". They are labels that provide for multiplexing of
applications directly on the IP layer, with transport functionality
embedded in the application.</t>
<t>From a historical perspective, one should note that many
simplistic exchange designs have been built using UDP, and many of
them have not worked all that well. The use of UDP really should be
treated as designing a new transport. More generally, advice on the
use of UDP in new applications has been compiled in the <xref
target="RFC5405">Unicast UDP Usage Guidelines for Application
Designers</xref>.</t>
<t><xref target="RFC5238">Datagram Transport Layer Security</xref>
can be used to prevent eavesdropping, tampering, or message forgery.
Alternatively, UDP can run over IPsec.</t>
</section>
<section title="Transmission Control Protocol (TCP)">
<t><xref target="RFC0793">TCP</xref> is the predominant transport
protocol in use in the Internet, with a long history. It is
"reliable", as the term is used in protocol design: it delivers data
to its peer and provides acknowledgement to the sender, or it dies
trying. It has extensions for <xref target="RFC2581">Congestion
Control</xref> and <xref target="RFC3168">Explicit Congestion
Notification</xref>.</t>
<t>The user interface for TCP is a byte stream interface - an
application using TCP might "write" to it several times only to have
the data compacted into a common segment and delivered as such to
its peer. For message-stream interfaces, we generally use the <xref
target="RFC1006"> ISO Transport Service on TCP </xref><xref
target="RFC2126"></xref> in the application.</t>
<t><xref target="RFC5246">Transport Layer Security</xref> can be
used to prevent eavesdropping, tampering, or message forgery.
Alternatively, TCP can run over IPsec. Additionally, <xref
target="RFC4987"></xref> discusses mechanisms similar to SCTP and
DCCP's "cookie" approach that may be used to secure TCP sessions
against flooding attacks.</t>
<t>TCP has supported ongoing research since it was written. As a
result, the End to End research group has published a <xref
target="RFC4614">Roadmap for TCP Specification Documents</xref>
which will guide expectations in that area.</t>
</section>
<section title="Stream Control Transmission Protocol (SCTP)">
<t><xref target="RFC4960">SCTP</xref> is a more recent reliable
transport protocol that can be imagined as a TCP-like context
containing multiple separate and independent message streams (as
opposed to TCP's byte streams). The design of SCTP includes
appropriate congestion avoidance behavior and resistance to flooding
and masquerade attacks. As it uses a message stream interface as
opposed to TCP's byte stream interface, it may also be more
appropriate for the ISO Transport Service than RFC 1006/2126.</t>
<t>SCTP offers several delivery options. The basic service is
sequential non-duplicated delivery of messages within a stream, for
each stream in use. Since streams are independent, one stream may
pause due to head of line blocking while another stream in the same
session continues to deliver data. In addition, SCTP provides a
mechanism for bypassing the sequenced delivery service. User
messages sent using this mechanism are delivered to the SCTP user as
soon as they are received.</t>
<t>SCTP implements a simple "cookie" mechanism intended to limit the
effectiveness of flooding attacks by mutual authentication. This
demonstrates that the application is connected to the same peer, but
does not identify the peer. Mechanisms also exist for <xref
target="RFC5061">Dynamic Address Reconfiguration</xref>, enabling
peers to change addresses during the session and yet retain
connectivity. <xref target="RFC3436">Transport Layer Security</xref>
can be used to prevent eavesdropping, tampering, or message forgery.
Alternatively, SCTP can run over IPsec.</t>
</section>
<section title="Datagram Congestion Control Protocol (DCCP)">
<t><xref target="RFC4340">DCCP</xref> is an "unreliable" transport
protocol (e.g., one that does not guarantee message delivery) that
provides bidirectional unicast connections of congestion-controlled
unreliable datagrams. DCCP is suitable for applications that
transfer fairly large amounts of data and that can benefit from
control over the tradeoff between timeliness and reliability.</t>
<t>DCCP implements a simple "cookie" mechanism intended to limit the
effectiveness of flooding attacks by mutual authentication. This
demonstrates that the application is connected to the same peer, but
does not identify the peer. <xref target="RFC5238">Datagram
Transport Layer Security</xref> can be used to prevent
eavesdropping, tampering, or message forgery. Alternatively, DCCP
can run over IPsec.</t>
</section>
</section>
<section anchor="infrastructure" title="Infrastructure">
<section anchor="dns1" title="Domain Name System">
<t>To facilitate network management and operations, the Internet
Community has defined the <xref target="RFC1034">Domain Name System
(DNS)</xref><xref target="RFC1035"></xref>. Names are hierarchical:
a name like example.com is found registered with a .com registrar,
and within the associated network other names like
baldur.cincinatti.example.com can be defined, with obvious
hierarchy. Security extensions, which all a registry to sign the
records it contains and as a result demonstrate their authenticity,
are defined by the DNS Security Extensions <xref
target="RFC4033"></xref><xref target="RFC4034"></xref><xref
target="RFC4035"></xref>.</t>
<t>Similarly unrequired but useful is the ability for a device to
update its own DNS record. One could imagine a sensor, for example,
that is using <xref target="RFC4862">Stateless Address
Autoconfiguration</xref> to create an address to associate it with a
name using <xref target="RFC2136">DNS Dynamic Update</xref> or <xref
target="RFC3007">DNS Secure Dynamic Update</xref>.</t>
</section>
<section anchor="dhcp" title="Dynamic Host Configuration">
<t>As discussed in <xref target="ipv4"></xref> and <xref
target="ipv6"></xref>, IPv6 address assignment can be accomplished
using autoconfiguration but can also be accomplished using <xref
target="RFC2131">DHCP</xref> or <xref
target="RFC3315">DHCPv6</xref>. The best argument for the use of
autoconfiguration is a large number of systems that require little
more than a random number as an address; the argument for DHCP is
administrative control.</t>
<t>There are other parameters that may need to be allocated to
hosts, and these do require administrative configuration; examples
include the address of one's DNS server, keys if Secure DNS is in
use, and others.</t>
</section>
</section>
<section anchor="other-app" title="Other Applications">
<t>There are several applications that are widely used but are not
properly thought of as infrastructure.</t>
<section title="Network Time">
<t>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 <xref target="RFC1305">Network Time
Protocol</xref>, which is designed for synchronization to within a
few microseconds, and the <xref target="RFC4330">Simple Network Time
Protocol</xref> which is used to set real time clocks to within a
few milliseconds. The former is more precise, but relies on frequent
exchanges; the latter is less precise and lower overhead.</t>
<t>NTP is currently being updated in <xref
target="I-D.ietf-ntp-ntpv4-proto"></xref>.</t>
</section>
<section title="Session Initiation Protocol">
<t>The <xref target="RFC3261">Session Initiation
Protocol</xref><xref target="RFC3265"></xref><xref
target="RFC3853"></xref><xref target="RFC4320"></xref><xref
target="RFC4916"></xref><xref target="RFC5393"></xref><xref
target="RFC5621"></xref> is an application layer control (signaling)
protocol for creating, modifying and terminating multimedia sessions
on the Internet, meant to be more scalable than H.323. Multimedia
sessions can be voice, video, instant messaging, shared data, and/or
subscriptions of events. SIP can run on top of TCP, UDP, SCTP, or
TLS over TCP. SIP is independent of the transport layer, and
independent of the underlying IPv4/v6 version. In fact, the
transport protocol used can change as the SIP message traverses SIP
entities from source to destination.</t>
<t>SIP itself does not choose whether a session is voice or video,
the <xref target="RFC4566">SDP: Session Description Protocol</xref>
is intended for that purpose and to identify the actual endpoints'
IP addresses. Within the SDP, which is transported by SIP, codecs
are offered and accepted (or not), the port number and IP address is
decided for where each endpoint wants to receive their <xref
target="RFC3550">RTP</xref> packets. This part is critical to
understand because of the affect on NATs. Unless a NAT (with or
without a Firewall) is 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 particular session - and resetting it based on
the <xref target="RFC5389">Session Traversal Utilities for
NAT</xref>, the session established by SIP will not 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 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 from being
received by the UA establishing the session.</t>
</section>
<section anchor="ical" title="Calendaring">
<t>Internet calendaring, as implemented in Apple iCal, Microsoft
Outlook and Entourage, and Google Calendar, is specified in <xref
target="RFC5545">Internet Calendaring and Scheduling Core Object
Specification (iCalendar)</xref> and is in the process of being
updated to an XML schema in <xref
target="I-D.daboo-et-al-icalendar-in-xml">iCalendar XML
Representation</xref> Several protocols exist to carry calendar
events, including <xref target="RFC2446"> Transport-Independent
Interoperability Protocol (iTIP)</xref>, (which has recently been
updated in <xref target="I-D.ietf-calsify-2446bis"></xref>) , the
<xref target="RFC2447"> Message-Based Interoperability Protocol
(iMIP)</xref> , and open source work on the <xref target="RFC5023">
Atom Publishing Protocol</xref>.</t>
</section>
</section>
</section>
<section anchor="network"
title="A simplified view of the business architecture">
<t>The Internet was originally structured in such a way that any host
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 found
ways to change that. To understand the implications, one must
understand, at a high level, the business structure of the Internet.</t>
<t>The Internet, whose name implies that it is a network of networks,
may be understood as a number of interconnected and independently
operated networks. Understanding "business" in an extended sense (a
legal entity, capable of entering into a contract, which includes wide
variety of entities including those narrowly termed "businesses"), this
can be thought of as a "business structure" for the Internet. Central to
its business structure are the networks that provide connectivity to
other networks, called "Transit Providers". These networks sell bulk
bandwidth and routing services to each other and to other networks as
customers. Around the periphery of these networks, one finds companies,
schools, and other networks that provide services directly to
individuals. These might generally be divided into "Enterprise Networks"
and "Access Networks"; Enterprise networks provide "free" connectivity
to their own employees or members, and also provide them a set of
services including electronic mail, web services, and so on. Access
Networks sell broadband connectivity (DSL, Cable Modem, 802.11 wireless
or 3GPP wireless), or "dial" services including PSTN dial-up and ISDN,
to subscribers. The subscribers are typically either residential or
small office/home office (SOHO) customers. Residential customers are
generally entirely dependent on their access provider for all services,
while a SOHO buys some services from the access provider 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 <xref
target="business-architecture"></xref>.</t>
<figure anchor="business-architecture"
title="Conceptual model of Internet businesses">
<artwork align="center"><![CDATA[
------ ------
/ \ / \
/--\ / \ / \
|SOHO|---+ Access | |Enterprise|
\--/ | Service | | Network |
/--\ | Provider| | |
|Home|---+ | ------ | |
\--/ \ +---+ +---+ /
\ / / \ \ /
------ | Transit | ------
| Service |
| Provider |
| |
\ /
\ /
------
]]></artwork>
</figure>
<t>A specific example is shown in a traceroute from the author's home to
a school he can see nearby. Internet connectivity in <xref
target="traceroute"></xref> passes through <list style="symbols">
<t>The author's home,</t>
<t>Cox Communications, an Access Network using Cable Modem
technology,</t>
<t>TransitRail, a commodity peering service for research and
education (R&E) networks,</t>
<t>Corporation for Education Network Initiatives in California
(CENIC), a transit provider for educational networks, and</t>
<t>the University of California at Santa Barbara, which in this
context might be viewed as an access network for its students and
faculty or as an enterprise network.</t>
</list></t>
<figure anchor="traceroute"
title="Traceroute from residential customer to educational institution">
<artwork align="center"><![CDATA[
<stealth-10-32-244-218:> fred% traceroute www.ucsb.edu
traceroute to web.ucsb.edu (128.111.24.41),
64 hops max, 40 byte packets
1 fred-vpn (10.32.244.217) 1.560 ms 1.108 ms 1.133 ms
2 wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1) 12.540 ms ...
3 68.6.13.101 ...
4 68.6.13.129 ...
5 langbbr01-as0.r2.la.cox.net ...
6 calren46-cust.lsanca01.transitrail.net ...
7 dc-lax-core1--lax-peer1-ge.cenic.net ...
8 dc-lax-agg1--lax-core1-ge.cenic.net ...
9 dc-ucsb--dc-lax-dc2.cenic.net ...
10 r2--r1--1.commserv.ucsb.edu ...
11 574-c--r2--2.commserv.ucsb.edu ...
12 * * *
]]></artwork>
</figure>
<t>Another specific example could be shown in a traceroute from the
author's home to his employer. Internet connectivity in that case uses a
Virtual Private Network (VPN tunnel) from the author's home, crossing
Cox Cable (an Access Network) and Pacific Bell (a Transit Network), and
terminating in Cisco Systems (an Enterprise Network); a traceroute of
the path doesn't show that as it is invisible within the VPN and the
contents of the VPN are invisible, due to encryption, to the networks on
the path. Instead, the traceroute in <xref target="enterprise"></xref>
is entirely within Cisco's internal network.</t>
<figure anchor="enterprise" title="Traceroute across VPN">
<artwork align="center"><![CDATA[
<stealth-10-32-244-218:~> fred% traceroute irp-view13
traceroute to irp-view13.cisco.com (171.70.120.60),
64 hops max, 40 byte packets
1 fred-vpn (10.32.244.217) 2.560 ms 1.100 ms 1.198 ms
<tunneled path through Cox and Pacific Bell>
2 ****
3 sjc24-00a-gw2-ge2-2 (10.34.251.137) 26.298 ms...
4 sjc23-a5-gw2-g2-1 (10.34.250.78) 25.214 ms ...
5 sjc20-a5-gw1 (10.32.136.21) 23.205 ms ...
6 sjc12-abb4-gw1-t2-7 (10.32.0.189) 46.028 ms ...
7 sjc5-sbb4-gw1-ten8-2 (171.*.*.*) 26.700 ms ...
8 sjc12-dc5-gw2-ten3-1 ...
9 sjc5-dc4-gw1-ten8-1 ...
10 irp-view13 ...
]]></artwork>
</figure>
<t>In both cases, it will be observed that the author's home internally
uses address space from the <xref target="RFC1918">Address Allocation
for Private Internets</xref>, and other networks generally use public
address space. It will also be observed that on entry to UCSB, the
traceroute in <xref target="traceroute"></xref> terminates before
arriving at the target.</t>
<t>Three middleware technologies are in obvious use here. These are the
use of a firewall, a Network Address Translator (NAT), and a Virtual
Private Network (VPN).</t>
<t>Firewalls are generally sold as, and considered, a security
technology. A firewall imposes a border between two administrative
domains, which are usually a residential, SOHO, or enterprise network
and its access or transit provider. In its essence, a firewall is a data
diode, imposing a policy on what sessions may pass between a protected
domain and the rest of the Internet. Simple policies generally permit
sessions to be originated from the protected network but not from the
outside; more complex policies may permit additional sessions from the
outside, as electronic mail to a mail server or a web session to a web
server, and may prevent certain applications from global access even
though they are originated from the inside. Firewalls are controversial
in the Internet community; network managers often insist on them simply
because they impose a boundary; others point out that their value as a
security solution is debatable, as most attacks come from behind the
firewall and application layer attacks such as viruses carried in email
or Active X are invisible to them. In general, as a security solution,
they are justified as a defense in depth; while the end system must in
the end be responsible for its own security, a firewall can inhibit or
prevent certain kinds of attacks from certain quarters such as the
consumption of CPU time on a critical server. Key documents describing
firewall technology and the issues it poses include:<list
style="symbols">
<t><xref target="RFC2588">IP Multicast and Firewalls</xref></t>
<t><xref target="RFC2647">Benchmarking Terminology for Firewall
Performance</xref></t>
<t><xref target="RFC2979">Behavior of and Requirements for Internet
Firewalls</xref></t>
<t><xref target="RFC3511">Benchmarking Methodology for Firewall
Performance</xref></t>
<t><xref target="RFC4487">Mobile IPv6 and Firewalls: Problem
Statement</xref></t>
<t><xref target="RFC5207">NAT and Firewall Traversal Issues of Host
Identity Protocol Communication</xref></t>
</list></t>
<t>Network Address Translation is a technology that was developed in
response to ISP behaviors in the mid-1990's; when <xref
target="RFC1918"></xref> was published, many ISPs started handing out
single or small numbers of addresses, and edge networks were forced to
translate. In time, this became considered a good thing, or at least not
a bad thing; it amplified the public address space, and it was sold as
if it were a firewall. It of course is not; while traditional dynamic
NATs only translate between internal and external session address/aport
tuples during the detected duration of the session, that session state
may exist in the network much longer than it exists on the end system,
and as a result constitutes an attack vector. The design, value, and
limitations of network address translation are described in: <list
style="symbols">
<t><xref target="RFC2663">IP Network Address Translator Terminology
and Considerations</xref></t>
<t><xref target="RFC3022">Traditional IP Network Address
Translator</xref></t>
<t><xref target="RFC3027">Protocol Complications with the IP Network
Address Translator</xref></t>
<t><xref target="RFC3235">Network Address Translator Friendly
Application Design Guidelines</xref></t>
<t><xref target="RFC3424">IAB Considerations for Network Address
Translation</xref></t>
<t><xref target="RFC3715">IPsec-Network Address Translation
Compatibility Requirements</xref></t>
<t><xref target="RFC4787">Network Address Translation Behavioral
Requirements for Unicast UDP</xref></t>
<t><xref target="RFC5128">State of Peer-to-Peer Communication across
Network Address Translators</xref></t>
<t><xref target="RFC5135">IP Multicast Requirements for a Network
Address Translator and a Network Address Port Translator</xref></t>
</list></t>
<t>Virtual Private Networks come in many forms; what they have in common
is that they are generally tunneled over the internet backbone, so that
as in <xref target="enterprise"></xref>, connectivity appears to be
entirely within the edge network although it is in fact across a service
provider's network. Examples include IPsec tunnel-mode encrypted
tunnels, IP-in-IP or <xref target="RFC2784">Generic Routing
Encapsulation (GRE)</xref> tunnels, and <xref target="RFC3031">MPLS
LSPs</xref><xref target="RFC3032"></xref>. .</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
<t>Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are required,
or if those assignments or registries are created during the RFC
publication process. From the author"s perspective, it may therefore be
removed upon publication as an RFC at the RFC Editor's discretion.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security is addressed in some detail in <xref
target="security-issues"></xref> and <xref
target="security-solutions"></xref>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Review comments were made by Andrew Yourtchenko, Ashok Narayanan,
Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, Hemant
Singh, James Polk, John Meylor, Joseph Salowey, Julien Abeille, Kerry
Lynn, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman, Ralph
Droms, Russ White, Sheila Frankel, and Toerless Eckert. Dave McGrew,
Vint Cerf, and Ralph Droms suggested text.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.1122" ?>
<?rfc include="reference.RFC.1123" ?>
<?rfc include="reference.RFC.1812" ?>
<?rfc include="reference.RFC.4294" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.daboo-et-al-icalendar-in-xml" ?>
<?rfc include="reference.I-D.ietf-6lowpan-hc" ?>
<?rfc include="reference.I-D.ietf-6man-node-req-bis" ?>
<?rfc include="reference.I-D.ietf-calsify-2446bis" ?>
<?rfc include="reference.I-D.ietf-ntp-ntpv4-proto" ?>
<?rfc include="reference.I-D.ietf-tls-rfc4347-bis" ?>
<?rfc include="reference.RFC.0768" ?>
<?rfc include="reference.RFC.0791" ?>
<?rfc include="reference.RFC.0792" ?>
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.0826" ?>
<?rfc include="reference.RFC.0894" ?>
<?rfc include="reference.RFC.1006" ?>
<?rfc include="reference.RFC.1034" ?>
<?rfc include="reference.RFC.1035" ?>
<?rfc include="reference.RFC.1112" ?>
<?rfc include="reference.RFC.1149" ?>
<?rfc include="reference.RFC.1195" ?>
<?rfc include="reference.RFC.1305" ?>
<?rfc include="reference.RFC.1332" ?>
<?rfc include="reference.RFC.1661" ?>
<?rfc include="reference.RFC.1918" ?>
<?rfc include="reference.RFC.2045" ?>
<?rfc include="reference.RFC.2046" ?>
<?rfc include="reference.RFC.2047" ?>
<?rfc include="reference.RFC.2049" ?>
<?rfc include="reference.RFC.2080" ?>
<?rfc include="reference.RFC.2126" ?>
<?rfc include="reference.RFC.2131" ?>
<?rfc include="reference.RFC.2136" ?>
<?rfc include="reference.RFC.2328" ?>
<?rfc include="reference.RFC.2357" ?>
<?rfc include="reference.RFC.2446" ?>
<?rfc include="reference.RFC.2447" ?>
<?rfc include="reference.RFC.2453" ?>
<?rfc include="reference.RFC.2460" ?>
<?rfc include="reference.RFC.2464" ?>
<?rfc include="reference.RFC.2474" ?>
<?rfc include="reference.RFC.2475" ?>
<?rfc include="reference.RFC.2516" ?>
<?rfc include="reference.RFC.2545" ?>
<?rfc include="reference.RFC.2549" ?>
<?rfc include="reference.RFC.2581" ?>
<?rfc include="reference.RFC.2588" ?>
<?rfc include="reference.RFC.2615" ?>
<?rfc include="reference.RFC.2647" ?>
<?rfc include="reference.RFC.2663" ?>
<?rfc include="reference.RFC.2710" ?>
<?rfc include="reference.RFC.2784" ?>
<?rfc include="reference.RFC.2979" ?>
<?rfc include="reference.RFC.3007" ?>
<?rfc include="reference.RFC.3022" ?>
<?rfc include="reference.RFC.3027" ?>
<?rfc include="reference.RFC.3031" ?>
<?rfc include="reference.RFC.3032" ?>
<?rfc include="reference.RFC.3168" ?>
<?rfc include="reference.RFC.3235" ?>
<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.3265" ?>
<?rfc include="reference.RFC.3275" ?>
<?rfc include="reference.RFC.3315" ?>
<?rfc include="reference.RFC.3376" ?>
<?rfc include="reference.RFC.3424" ?>
<?rfc include="reference.RFC.3436" ?>
<?rfc include="reference.RFC.3453" ?>
<?rfc include="reference.RFC.3511" ?>
<?rfc include="reference.RFC.3550" ?>
<?rfc include="reference.RFC.3590" ?>
<?rfc include="reference.RFC.3715" ?>
<?rfc include="reference.RFC.3810" ?>
<?rfc include="reference.RFC.3828" ?>
<?rfc include="reference.RFC.3850" ?>
<?rfc include="reference.RFC.3851" ?>
<?rfc include="reference.RFC.3853" ?>
<?rfc include="reference.RFC.3940" ?>
<?rfc include="reference.RFC.3971" ?>
<?rfc include="reference.RFC.4033" ?>
<?rfc include="reference.RFC.4034" ?>
<?rfc include="reference.RFC.4035" ?>
<?rfc include="reference.RFC.4262" ?>
<?rfc include="reference.RFC.4271" ?>
<?rfc include="reference.RFC.4289" ?>
<?rfc include="reference.RFC.4291" ?>
<?rfc include="reference.RFC.4301" ?>
<?rfc include="reference.RFC.4302" ?>
<?rfc include="reference.RFC.4303" ?>
<?rfc include="reference.RFC.4306" ?>
<?rfc include="reference.RFC.4307" ?>
<?rfc include="reference.RFC.4309" ?>
<?rfc include="reference.RFC.4320" ?>
<?rfc include="reference.RFC.4330" ?>
<?rfc include="reference.RFC.4340" ?>
<?rfc include="reference.RFC.4347" ?>
<?rfc include="reference.RFC.4410" ?>
<?rfc include="reference.RFC.4443" ?>
<?rfc include="reference.RFC.4487" ?>
<?rfc include="reference.RFC.4566" ?>
<?rfc include="reference.RFC.4604" ?>
<?rfc include="reference.RFC.4607" ?>
<?rfc include="reference.RFC.4614" ?>
<?rfc include="reference.RFC.4787" ?>
<?rfc include="reference.RFC.4835" ?>
<?rfc include="reference.RFC.4861" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.4916" ?>
<?rfc include="reference.RFC.4919" ?>
<?rfc include="reference.RFC.4941" ?>
<?rfc include="reference.RFC.4944" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.4987" ?>
<?rfc include="reference.RFC.5023" ?>
<?rfc include="reference.RFC.5061" ?>
<?rfc include="reference.RFC.5072" ?>
<?rfc include="reference.RFC.5128" ?>
<?rfc include="reference.RFC.5135" ?>
<?rfc include="reference.RFC.5207" ?>
<?rfc include="reference.RFC.5238" ?>
<?rfc include="reference.RFC.5246" ?>
<?rfc include="reference.RFC.5308" ?>
<?rfc include="reference.RFC.5340" ?>
<?rfc include="reference.RFC.5389" ?>
<?rfc include="reference.RFC.5393" ?>
<?rfc include="reference.RFC.5405" ?>
<?rfc include="reference.RFC.5545" ?>
<?rfc include="reference.RFC.5621" ?>
<reference anchor="SP-MULPIv3.0">
<front>
<title>DOCSIS 3.0 MAC and Upper Layer Protocols Interface
Specification, CM-SP-MULPIv3.0-I10-090529</title>
<author fullname="CableLabs" surname="CableLabs">
<organization>Cisco Systems</organization>
</author>
<date month="May" year="2009" />
</front>
<format target="http://blogs.cisco.com/datacenter/comments/ethernet_over_barbed_wire_arcnet_100mb_token_ring_100base_vganylan_and_iscs/"
type="HTML" />
</reference>
<reference anchor="Chapman">
<front>
<title>Ethernet over Barbed Wire, Arcnet, 100MB Token Ring,
100Base-VGAnylan and iSCSI ...</title>
<author fullname="Ed Chapman" initials="E." surname="Chapman">
<organization>Cisco Systems</organization>
</author>
<date month="" year="2007" />
</front>
<format target="http://blogs.cisco.com/datacenter/comments/ethernet_over_barbed_wire_arcnet_100mb_token_ring_100base_vganylan_and_iscs/"
type="HTML" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:34:11 |