One document matched: draft-baker-ietf-core-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!--
#
# sg-ietf-compendium.xml
#
# aka draft-baker-ietf-core
#
# David Meyer
# dmm@1-4-5.net
# Tue Aug 10 06:38:22 PDT 2010
#
# $Header: /home/dmm/IETF/Drafts/active/ietf-core/RCS/sg-ietf-compendium.xml,v 1.3 2010/08/16 16:55:49 dmm Exp $
#
-->
<!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-07" 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>
<author fullname="David Meyer" initials="D.M." surname="Meyer">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Eugene</city>
<code>97403</code>
<region>Oregon</region>
<country>USA</country>
</postal>
<email>dmm@cisco.com</email>
</address>
</author>
<date year="2010" />
<area>General</area>
<workgroup></workgroup>
<abstract>
<t>This note identifies the key protocols of the Internet Protocol Suite
for use in the Smart Grid. The target audience is those people seeking
guidance on how to construct an appropriate Internet Protocol Suite
profile for the Smart Grid. In practice, such a profile would consist of
selecting what is needed for Smart Grid deployment from the picture
presented here.</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>This document provides Smart Grid designers with advice on how to
best "profile" the Internet Protocol Suite (IPS) for use on with Smart
Grids. It provides an overview of the IPS and the key protocols that are
critical in integrating Smart Grid devices into an IP-based
infrastructure.</t>
<t>The IPS provides options for several key architectural components.
For example, the IPS provides several choices for the traditional
transport function between two systems: the Transmission Control
Protocol (TCP) <xref target="RFC0793"></xref>, the Stream Control
Transmission Protocol (SCTP) <xref target="RFC4960"></xref>, and the
Datagram Congestion Control Protocol (DCCP) <xref
target="RFC4340"></xref>. Another option is to select an encapsulation
such as the User Datagram Protocol (UDP) <xref target="RFC0768"></xref>
which essentially allows an application to implement its own transport
service. In practice, a designer will pick a transport protocol which is
appropriate to the problem being solved.</t>
<t>The IPS is standardized by the Internet Engineering Task Force
(IETF). IETF protocols are documented in the Request for Comment (RFC)
series. Several RFCs have been written describing how the IPS should be
implemented. 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 is intended to provide Smart Grid architects and
designers with a compendium of relevant RFCs (and to some extent
Internet Drafts), and is organized as an annotated list of RFCs. To that
end, the remainder of this document is organized as follows: <xref
target="suite"></xref> describes the Internet Architecture and its
protocol suite. <xref target="protocols"></xref> outlines the set of
protocols that will be useful in Smart Grid deployment. Finally, <xref
target="network"></xref> provides an overview of the business
architecture embodied in the design and deployment of the IPS.</t>
</section>
<section anchor="suite" title="The Internet Protocol Suite">
<t>Before enumerating the list of Internet protocols relevant to Smart
Grid, we discuss the layered architecture of the IPS, the functions of
the various layers, and their associated protocols.</t>
<section anchor="architecture" title="Internet Protocol Layers">
<t>While Internet architecture uses the definitions and language
similar to language used by the ISO Open System Interconnect Reference
(ISO-OSI) Model (<xref target="iso-osi"></xref>), it actually predates
that model. As a result, there is some skew in terminology. For
example, the ISO-OSI model uses "end system" while the Internet
architecture uses "host. Similarly, an "intermediate system" in the
ISO-OSI model is called an "internet gateway" or "router" in Internet
parlance. Notwithstanding these differences, the fundamental concepts
are largely 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 is shown in <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 the Internet model, the Application, Presentation, and Session
layers are compressed into a single entity called "the application".
For example, the Simple Network Management Protocol (SNMP) <xref
target="RFC1157"></xref> describes an application that encodes its
data in an ASN.1 profile and engages in a session to manage a
network element. The point here is that in the Internet the
distinction between these layers exists but is not highlighted.
Further, note that in <xref target="irm"></xref> these functions 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 concepts
in the communication architecture, to large extent 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". For
example, optical network engineers refer to optical fiber and
associated electronics as "the transport", while web designers refer
to the Hypertext Transfer Protocol (HTTP) <xref
target="RFC2616"></xref> (an application layer protocol) as "the
transport".</t>
<t>In the Internet protocol stack, the "transport" is the lowest
protocol layer that travels end-to-end unmodified, and is
responsible for end-to-end data delivery services. In the Internet
the transport layer is the layer above the network layer. Transport
layer protocols have a single minimum requirement: the ability to
multiplex several applications on one IP address. <xref
target="RFC0768">UDP</xref>, <xref target="RFC0793">TCP</xref>,
<xref target="RFC4340">DCCP</xref>, <xref
target="RFC4960">SCTP</xref>, and <xref target="RFC5740">NORM</xref>
each accomplish this using a pair of port numbers, one for the
sender and one for the receiver. A port number identifies an
application instance, which might be a general "listener" that peers
or clients may open sessions with, or a specific correspondent with
such a "listener". The session identification in an IP datagram is
often called the "five-tuple", and consists of the source and
destination IP addresses, the source and destination ports, and an
identifier for the transport protocol in use.</t>
<t>In addition, the responsibilities of a specific transport layer
protocol typically includes 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. For example, TCP 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 main function of the network layer is to identify a remote
destination and deliver data to it. In connection-oriented networks
such as Multi-protocol Label Switching (MPLS) <xref
target="RFC3031"></xref> or Asynchronous Transfer Mode (ATM), a path
is set up once, and data is delivered through it. In connectionless
networks such as Ethernet and IP, data is delivered as datagrams.
Each datagram contains both the source and destination network layer
addresses, and the network is responsible for delivering it. In the
Internet Protocol Suite, the Internet Protocol is the network that
runs end to end. It may be encapsulated over other LAN and WAN
technologies, including both IP networks and networks of other
types.</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
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 IPS and applications
that use those protocol unchanged.</t>
</section>
<section title="Lower layer networks">
<t>The network layer can recursively subdivided as needed. This
may be accomplished by tunneling, in which an IP datagram is
encapsulated in another IP header for delivery to a decapsulator.
IP is frequently carried in Virtual Private Networks (VPNs) across
the public Internet using tunneling technologies such as the
Tunnel mode of IPsec, IP-in-IP, and Generic Route Encapsulation
(GRE) <xref target="RFC2784"></xref>. In addition, IP is also
frequently carried in circuit networks such as MPLS <xref
target="RFC4364"></xref>, GMPLS, and ATM. Finally, IP is also
carried over local wireless (IEEE 802.11, 802.15.4, or 802.16)
networks and switched Ethernet (IEEE 802.3) networks.</t>
</section>
</section>
<section title="Media layers: Physical and Link">
<t>At the lowest layer of the IP architecture, data is encoded in
messages and transmitted over the physical media. While the IETF
specifies algorithms for carrying IPv4 and IPv6 various media types,
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>While it is popular to complain about the security of the Internet,
solutions to many Internet security problems already exist but have
not been widely deployed. Internet security solutions 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 generally center on
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. As a result,
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 considered to be a protocol problem.</t>
</section>
<section title="Session identification">
<t>At the transport and application layers and in lower layer
networks where dynamic connectivity such as ATM Switched Virtual
Circuits (SVCs) or "dial" connectivity are in use, there tend to be
several different classes of authentication/authorization
requirements. The basic requirements that must be satisfied are:
<list style="numbers">
<t>Verify that peers 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, both the communications channel itself and
message exchanges (both by knowing the source of the information and
to have proof of its validity) must be secured. Three examples
suffice to illustrate the challenges.</t>
<t>One common attack against a TCP session is to bombard the session
with reset messages. Other attacks against TCP include the "SYN
flooding" attack, in which an attacker attempts to exhaust the
memory of the target by creating TCP state. Experience has shown
that by including information in the transport header or a related
protocol like the IPsec (<xref target="ipsec"></xref>) or TLS (<xref
target="tls"></xref>), a host can identify legitimate messages and
discard mitigate any damage that may have been caused by the
attack.</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. To protect against such attacks, an
Internet Service Provider (ISP) should not accept information from
new peers without verifying that the peer is who it claims to be and
that the peer is authorized to carry on the exchange of
information.</t>
<t>More generally, in order to secure a communications channel, it
must be possible to verify that messages putatively received from a
peer were in fact received from that peer. Only once messages are
verified as coming a trusted peer should a host or router engage in
communications with the peer.</t>
<t>Unfortunately, even trusted peers forward incorrect or malicious
data. As a result, securing the channel is not sufficient;
information exchanged through the channel must also be secured. 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>
</section>
<section title="Confidentiality">
<t>In addition to securing the communications channel and messaging,
there frequently a requirement for confidentiality. Confidentiality
arises at several layers, sometimes simultaneously. For example,
providers of credit card transaction services want application layer
privacy, which can be supplied by encrypting application data or by
an encrypted transport layer. If an ISP (or other entity) wants to
hide its network structure, it can 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, and as such are surveyed
here.</t>
<section anchor="dns" title="Domain Name System (DNS)">
<t>The DNS' main function is translating names to numeric IP
addresses. While this is 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 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. DNS and DNSSEC are discussed further in <xref
target="dns1"></xref>.</t>
</section>
<section title="Network Management">
<t>Network management has proven to be a difficult problem. As such,
various solutions have been proposed, implemented, and deployed.
Each solution has its proponents, all of whom have solid arguments
for their viewpoints. The IETF has two major network management
solutions for device operation: SNMP, which is ASN.1-encoded and is
primarily used for monitoring of system variables and is a polled
architecture, and NetConf <xref target="RFC4741"></xref>, 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, which is discussed in <xref
target="dhcp"></xref>. Note that Smart Grid deployments may require
identity authentication and authorization (as well as other
provisioning and configuration) that may not be within the scope of
either DHCP or 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 IP architecture and some
of the problems that the architecture tries to address, we introduce
specific protocols that might be appropriate to various Smart Grid use
cases. Use cases should be analyzed along privacy, AAA, transport and
network solution dimensions. The following sections provide guidance for
such analyzes.</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 mitigation strategies at each
layer. The following sections outline the security features of the
IPS.</t>
<section title="Session identification, authentication, authorization, and accounting">
<t>The IPS provides approaches to Authentication, Authorization, and
Accounting (AAA) issues. Since these different approaches have
different attack surfaces and protection domains, they require some
thought in application. The two major approaches to AAA taken by the
IPS are the IP Security Architecture (<xref target="ipsec"></xref>),
which protects IP datagrams, and Transport Layer Security (<xref
target="tls"></xref>), which protects the information which the
transport layer delivers.</t>
</section>
<section anchor="ipsec" title="IP Security Architecture (IPsec)">
<t>The <xref target="RFC4301">Security Architecture for the Internet
Protocol (IPsec)</xref> is a set of control and data protocols that
are implemented between IPv4 and the chosen transport layer, or in
IPv6's security extension header. It allows transport layer sessions
to communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery. As is typical with IETF
specifications, the architecture is spelled out in a number of
documents which specify the 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>IPsec provides two modes: Transport mode and tunnel mode. In
transport mode, IPsec ESP encrypts the transport layer and the
application data. In tunnel mode, the source IP datagram is
encrypted and encapsulated in a second IP header addressed to the
intended decryptor. As might be expected, tunnel mode is frequently
used for virtual private networks which need to securely transmit
data across networks with unknown (or no) other security properties.
In both cases, authentication, authorization, and confidentiality
extend from system to system, and apply to all applications that the
two systems use.</t>
</section>
<section anchor="tls" 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 protocol data unit, 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. Authentication, authorization, and
confidentiality exist for a session between specific
applications.</t>
<t>When used in conjunction with <xref target="IEEE802.1X">IEEE
802.1X</xref>, <xref target="RFC5216">EAP-TLS</xref> is widely
considered to offer excellent access security to a wired or wireless
IEEE 802 LAN (IEEE 802.1X in conjunction with EAP-TLS is the
baseline for Zigbee SEP 2.0). Note that one potential drawback of
802.1X technology is that it requires deployment of client-side
certificates, which is frequently seen as a deployment barrier.</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="RFC5750"></xref> <xref target="RFC5751"></xref> <xref
target="RFC4262"></xref> specification was originally designed 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>Related work includes the use of digital signatures on
XML-encoded files, which has been jointly standardized by W3C and
the IETF <xref target="RFC3275"></xref>.</t>
</section>
</section>
<section title="Network Layer">
<t>The IPS specifies two network layer protocols: IPv4 and IPv6. The
following sections describe the IETF's coexistence and transition
mechanisms for IPv4 and IPv6.</t>
<t>Note that since IPv4 free pool (the pool of available, unallocated
IPv4 addresses) is almost exhausted, the IETF recommends that new
deployments use IPv6 and that IPv4 infrastructures are supported via
the mechanisms described in <xref target="transition"></xref>.</t>
<section anchor="transition" title="IPv4/IPv6 Coexistence Advice">
<t>The IETF has specified a variety of mechanisms designed to
facilitate IPv4/IPv6 coexistence. The IETF actually recommends
relatively few of them: the current advice to network operators is
found in <xref
target="I-D.arkko-ipv6-transition-guidelines">Guidelines for Using
IPv6 Transition Mechanisms</xref>. The thoughts in that document are
replicated here.</t>
<section anchor="DualStack" title="Dual Stack Coexistence">
<t>The simplest coexistence approach is to <list style="symbols">
<t>provide a network that routes both IPv4 and IPv6,</t>
<t>ensure that servers similarly support both protocols,
and</t>
<t>require that all new systems purchased or upgraded support
both protocols.</t>
</list></t>
<t>The net result is that over time all systems become protocol
agnostic, and that eventually maintenance of IPv4 support becomes
a business decision. This approach is described in the <xref
target="RFC4213">Basic Transition Mechanisms for IPv6 Hosts and
Routers</xref>.</t>
</section>
<section anchor="6rd" title="Tunneling Mechanism">
<t>In those places in the network that support only IPv4 the
simplest and most reliable approach is to provide virtual
connectivity using tunnels or encapsulations. Early in the IPv6
deployment, this was often done using static tunnels. A more
dynamic approach is documented in <xref
target="RFC5569">IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)</xref>.</t>
</section>
<section anchor="v6v4"
title="Translation between IPv4 and IPv6 Networks">
<t>In those cases where an IPv4-only host would like to
communicate with an IPv6-only host (or vice versa), protocol
translation may be indicated. At first blush, protocol translation
may appear trivial; on deeper inspection it turns out that
protocol translation can be complicated.</t>
<t>The most reliable approach to protocol translation is to
provide application layer proxies or gateways, which natively
enable application-to-application connections using both protocols
and can use whichever is appropriate. For example, a web proxy
might use both protocols and as a result enable an IPv4-only
system to run HTTP across on IPv6-only network or to a web server
that implements only IPv6. Since this approach is a service of a
protocol-agnostic server, it is not the subject of standardization
by the IETF.</t>
<t>For those applications in which network layer translation is
indicated, the IETF has designed a translation mechanism which is
described in the following documents: <list style="symbols">
<t><xref target="I-D.ietf-behave-v6v4-framework">Framework for
IPv4/IPv6 Translation</xref></t>
<t><xref target="I-D.ietf-behave-address-format">IPv6
Addressing of IPv4/IPv6 Translators</xref></t>
<t><xref target="I-D.ietf-behave-dns64">DNS extensions
</xref></t>
<t><xref target="I-D.ietf-behave-v6v4-xlate">IP/ICMP
Translation Algorithm</xref></t>
<t><xref
target="I-D.ietf-behave-v6v4-xlate-stateful">Translation from
IPv6 Clients to IPv4 Servers</xref></t>
</list></t>
<t>As with IPv4/IPv4 Network Address Translation, translation
between IPv4 and IPv6 has limited real world applicability: any
application protocol that carries IP addresses and expects them to
be meaningful to both client and server or to both peers will have
trouble when the addresses are transparently translated. However,
for those protocols that do not, protocol translation can provide
a useful network extension.</t>
<t>Network-based translation provides for two types of services:
stateless (and therefore scalable and load-sharable) translation
between IPv4 and IPv6 addresses that embed an IPv4 address in
them, and stateful translation similar to IPv4/IPv4 translation
between IPv4 addresses. The stateless mode is straightforward to
implement, but due to the embedding, requires IPv4 addresses to be
allocated to an otherwise IPv6-only network, and is primarily
useful for IPv4-accessible servers implemented in the IPv6
network. The stateful mode allows clients in the IPv6 network to
access servers in the IPv4 network, but does not provide such
service for IPv4 clients accessing IPv6 peers or servers with
general addresses; it does however have the advantage that it does
not require that a unique IPv4 address be embedded in the IPv6
address of hosts using this mechanism.</t>
</section>
</section>
<section anchor="ipv4" title="Internet Protocol Version 4">
<t><xref target="RFC0791">IPv4</xref> and the <xref
target="RFC0792">Internet Control Message Protocol</xref> comprise
the IPv4 network layer. IPv4 provides unreliable delivery of
datagrams.</t>
<t>IPv4 also provides for fragmentation and reassembly of long
datagrams for transmission through networks with small Maximum
Transmission Units (MTU). The MTU is the largest packet size that
can be delivered across the network. In addition, the IPS provides
the Internet Control Message Protocol (ICMP) <xref
target="RFC0792"></xref>, which is a separate protocol that 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 <xref target="RFC1195">OSI IS-IS for IPv4 (IS-IS)
</xref> and <xref target="RFC2328">OSPF Version 2</xref> interpreted
as control traffic; this control traffic is assured of not being
dropped when queued or upon receipt even if other traffic is being
dropped.. These control bits turned out to be less useful than the
designers had hoped. They were replaced by the <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 accomplished by routing
applications that exchange connectivity information and build
semi-static destination routing databases. If a datagram is
directed to a given destination address, the address is looked up
in the routing database, and the most specific ("longest") prefix
found that contains it is used to identify the next hop router, or
the end system 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 part of the core
Internet architecture but may be of interest in the Smart Grid is
the development of so-called "Reliable Multicast". This is
"so-called" because it is not "reliable" in the strict sense of
the word - it is perhaps better described as "enhanced
reliability". A best effort network by definition can lose
traffic, duplicate it, or reorder it, something as true for
multicast as for unicast. Research in "Reliable Multicast"
technology intends to improve the probability of delivery of
multicast traffic.</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="RFC5740"> 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 Advanced Metering Infrastructure 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. In addition, IPv6 addresses may also be
autoconfigured. Autoconfiguation enables various different models
of network management which may be advantageous in various use
cases. 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 accomplished by routing
applications that exchange connectivity information and build
semi-static destination routing databases. If a datagram is
directed to a given destination address, the address is looked up
in the routing database, and the most specific ("longest") prefix
found that contains it is used to identify the next hop router, or
the end system it will be delivered to. Routing is not generally
implemented on hosts (although it can be); generally, a host sends
datagrams to a router on its local network, and the router carries
out the intent.</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>
<section anchor="Routing" title="Routing for IPv4 and IPv6">
<t></t>
<section anchor="RIP" title="Routing Information Protocol">
<t>The prototypical routing protocol used in the Internet has
probably been the <xref target="RFC1058">Routing Information
Protocol</xref>. People that use it today tend to deploy <xref
target="RFC2080">RIPng for IPv6</xref> and <xref
target="RFC2453">RIP Version 2</xref>. Briefly, RIP is a distance
vector routing protocol that is based on a distributed variant of
the widely known Bellman-Ford algorithm. In distance vector
routing protocols, each router announces the contents of its route
table to neighboring routers, which integrate the results with
their route tables and re-announce them to others. It has been
characterized as "routing by rumor", and suffers many of the ills
we find in human gossip - propagating stale or incorrect
information in certain failure scenarios, and being in cases
unresponsive to changes in topology. <xref
target="RFC1058"></xref> provides guidance to algorithm designers
to mitigate these issues.</t>
</section>
<section anchor="OSPF" title="Open Shortest Path First">
<t>The Open Shortest Path First (OSPF) routing protocol is one of
the more widely used protocols in the Internet. OSPF is a based on
Dijkstra's well known shortest path first (SPF) algorithm. It is
implemented as <xref target="RFC2328">OSPF Version 2</xref> for
IPv4, <xref target="RFC5340">OSPF for IPv6</xref> for IPv6, and
the <xref target="RFC5838">Support of Address Families in
OSPFv3</xref> to enable <xref target="RFC5340"></xref> to route
both IPv4 and IPv6.</t>
<t>The advantage of any SPF-based protocol (i.e., OSPF and IS-IS)
is primarily that every router in the network constructs its view
of the network from first hand knowledge rather than the "gossip"
that distance vector protocols propagate. As such, the topology is
quickly and easily changed by simply announcing the change. The
disadvantage of SPF-based protocols is that each router must store
a first-person statement of the connectivity of each router in the
domain.</t>
</section>
<section anchor="ISIS"
title="ISO Intermediate System to Intermediate System">
<t>The Intermediate System to Intermediate System (IS-IS) routing
protocol is one of the more widely used protocols in the Internet.
IS-IS is also based on Dijkstra's SPF algorithm. It was originally
specified as ISO DP 10589 for the routing of CLNS, and extended
for <xref target="RFC1195">routing in TCP/IP and dual
environments</xref>, and more recently for <xref
target="RFC5308">routing of IPv6 </xref>.</t>
<t>As with OSPF, the positives of any SPF-based protocol and
specifically IS-IS are primarily that the network is described as
a lattice of routers with connectivity to subnets and isolated
hosts. It's topology is quickly and easily changed by simply
announcing the change, without the issues of "routing by rumor",
since every host within the routing domain has a first-person
statement of the connectivity of each router in the domain. The
negatives are a corollary: each router must store a first-person
statement of the connectivity of each router in the domain.</t>
</section>
<section anchor="BGP" title="Border Gateway Protocol">
<t>The <xref target="RFC4271">Border Gateway Protocol (BGP)
</xref> is widely used in the IPv4 Internet to exchange routes
between administrative entities - service providers, their peers,
their upstream networks, and their customers - while applying
specific policy. <xref target="RFC4760">Multi-protocol Extensions
</xref> to BGP allow BGP to carry <xref target="RFC2545">IPv6
Inter-Domain Routing</xref>, multicast reachability information,
and VPN information, among others.</t>
<t>Considerations that apply with BGP deal with the flexibility
and complexity of the policies that must be defined. Flexibility
is a good thing; in a network that is not run by professionals,
the complexity is burdensome.</t>
</section>
<section anchor="DYMO"
title="Dynamic MANET On-demand (DYMO) Routing">
<t>The Mobile Ad Hoc Working Group of the IETF developed, among
other protocols, the <xref target="RFC3561">Ad hoc On-Demand
Distance Vector (AODV) Routing</xref>. This protocol captured the
minds of some in the embedded devices industry, but experiences
issues in wireless networks such as 802.15.4 and 802.11's Ad Hoc
mode. As a result, it is in the process of being updated<xref
target="I-D.ietf-manet-dymo">Dynamic MANET On-demand (DYMO)
Routing</xref>.</t>
<t>AODV and DYMO are essentially reactive routing protocols
designed for mobile ad hoc networks, and usable in other forms of
ad hoc networks. They provide connectivity between a device within
a distributed subnet and a few devices (including perhaps a
gateway or router to another subnet) without tracking connectivity
to other devices. In essence, routing is calculated and discovered
upon need, and a host or router need only maintain the routes that
currently work and are needed.</t>
</section>
<section anchor="OLSR" title="Optimized Link State Routing Protocol">
<t>The <xref target="RFC3626">Optimized Link State Routing
Protocol (OLSR)</xref> is a proactive routing protocol designed
for mobile ad hoc networks, and can be used in other forms of ad
hoc networks. It provides arbitrary connectivity between device
within a distributed subnet. As with protocols designed for wired
networks, routing is calculated and maintained whenever changes
are detected, and maintained in each router's tables. The set of
nodes that operate as routers within the subnet, however, are
fairly fluid, and dependent on this instantaneous topology of the
subnet.</t>
</section>
<section anchor="RPL"
title="Routing for Low power and Lossy Networks">
<t>The <xref target="I-D.ietf-roll-rpl">RPL: IPv6 Routing Protocol
for Low power and Lossy Networks</xref> xxx</t>
</section>
</section>
<section title="IPv6 Multicast Forwarding and Routing">
<t>IPv6 specifies 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 anchor="PIM" title="Protocol-Independent Multicast Routing">
<t>xxx <xref target="RFC3973">Protocol Independent Multicast -
Dense Mode (PIM-DM): Protocol Specification (Revised)</xref> xxx
<xref target="RFC4601">Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised)</xref> xxx <xref
target="RFC3569">Source-Specific Multicast (SSM)</xref> xxx <xref
target="RFC4608">Source-Specific Protocol Independent Multicast
</xref> xxx <xref target="RFC5796">Authentication and
Confidentiality in Protocol Independent Multicast Sparse Mode
(PIM-SM) Link-Local Messages</xref> xxx</t>
</section>
</section>
<section title="Adaptation to lower layer networks and link layer protocols">
<t>In general, the layered architecture of the Internet enables the
IPS to run over any appropriate layer two architecture. The ability
to change the link or physical layer without having to rethink the
network layer, transports, or applications has been a great benefit
in the Internet.</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>This section outlines the functionality of UDP, TCP, SCTP, and
DCCP. UDP and TCP are best known and most widely used in the Internet
today, while SCTP and DCCP are newer protocols that built for specific
purposes. Other transport protocols can be built when required.</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>Many exchange designs have been built using UDP, and many of them
have not worked all that well. As a result, the use of UDP really
should be treated as designing a new transport. Advice on the use of
UDP in new applications can be found in <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
for applications that run over UDP. 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. 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="RFC5681">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>Finally, note that TCP has been the subject of ongoing research
and development since it was written. The End to End research group
has published a <xref target="RFC4614">Roadmap for TCP Specification
Documents</xref> to capture this history, to guide TCP implementors,
and provide context for TCP researchers.</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>In order 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>Devices can also optionally update their own DNS record. For
example, a sensor that is using <xref target="RFC4862">Stateless
Address Autoconfiguration</xref> to create an address might want 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 either autoconfiguration, <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
which require administrative configuration; examples include the
addresses of DNS servers, keys for Secure DNS and Network Time
servers.</t>
</section>
</section>
<section title="Service and Resource Discovery">
<t>Service and resource discovery are among the most important
protocols for constrained resource self-organizing networks. These
include various sensor networks as well as the Home Area Networks
(HANs), Building Area Networks (BANs) and Field Area Networks (FANs)
envisioned by Smart Grid architects.</t>
<section anchor="service-discovery" title="Service Discovery">
<t>Service discovery protocols are designed for the automatic
configuration and detection of devices, and the services offered by
the discovered devices. In many cases service discovery is performed
by so-called "constrained resource" devices (i.e., those with
limited processing power, memory, and power resources).</t>
<t>In general, service discovery is concerned with the assignment of
network addresses (perhaps via <xref target="RFC4862">Stateless
Address Autoconfiguration</xref>), resolution and distribution of
hostnames via <xref
target="I-D.cheshire-dnsext-multicastdns">multicast DNS</xref> and
the automatic location of network services via <xref
target="dhcp">DHCP</xref>, the <xref
target="I-D.cheshire-dnsext-dns-sd">DNS Service Discovery
(DNS-SD)</xref> (part of Apple's Bonjour technology), and the <xref
target="RFC2608">Service Location Protocol (SLP)</xref>.</t>
</section>
<section anchor="resource-discovery" title="Resource Discovery">
<t>Resource Discovery is concerned with the discovery resources
offered by end-points and is extremely important in
machine-to-machine closed-loop applications (i.e., those with no
humans in the loop). The goals of resource discover protocols
include: <list>
<t>Simplicity of creation and maintenance of resources</t>
<t>Commonly understood semantics</t>
<t>Conformance to existing and emerging standards</t>
<t>International scope and applicability</t>
<t>Extensibility</t>
<t>Interoperability among collections and indexing systems</t>
</list></t>
<t>The <xref target="I-D.ietf-core-coap">Constrained Application
Protocol (CoAP)</xref> is being developed in IETF with these goals
in mind. In particular, CoAP is designed for use in constrained
resource networks and for machine-to-machine applications such as
smart energy and building automation. It provides a RESTful transfer
protocol, a built-in resource discovery protocol, and includes web
concepts such as URIs and content-types. CoAP provides both unicast
and multicast resource discovery and includes the ability to filter
on attributes of resource descriptions. Finally, CoAP resource
discovery can also be used to discovery HTTP resources.</t>
<t>For simplicity, CoAP makes the assumption that all CoAP servers
listen on the default CoAP port or otherwise have been configured or
discovered using some general service discovery mechanism such as
<xref target="I-D.cheshire-dnsext-dns-sd">DNS Service Discovery
(DNS-SD)</xref>.</t>
<t>Resource discovery in CoAP is accomplished through the use of
well-known resources which describe the links offered by a CoAP
server. CoAP defines a well-known URI for discovery:
"/.well-known/r" <xref target="RFC5785"></xref>. For example, the
query [GET /.well-known/r] returns a list of links (representing
resources) available from the queried CoAP server. A query such as
[GET /.well-known/r?n=Voltage] returns the resources with the name
Voltage.</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="RFC5905">Network Time
Protocol</xref>.</t>
<t>NTP is currently being updated in <xref
target="RFC5905"></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">Real-time Transport Protocol (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="RFC5546"> iCalendar
Transport-Independent Interoperability Protocol (iTIP) </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 is a network of networks in which networks are
interconnected in specific ways and are independently operated. It is
important to note that the underlying Internet architecture puts no
restrictions on the ways that networks are interconnected;
interconnection is a business decision. As such, the Internet
interconnection architecture can be thought of as a "business structure"
for the Internet.</t>
<t>Central to the Internet business structure are the networks that
provide connectivity to other networks, called "Transit Networks". These
networks sell bulk bandwidth and routing services to each other and to
other networks as customers. Around the periphery of the transit network
are 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 a home to a nearby
school. Internet connectivity in <xref target="traceroute"></xref>
passes through <list style="symbols">
<t>The home network,</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 home
through a Virtual Private Network (VPN tunnel) from the 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>Note that in both cases, the home network uses private address space
<xref target="RFC1918"></xref> while other networks generally use public
address space, and that three middleware technologies are in 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 by many to be a
security technology. This is based on the fact that a firewall imposes a
border between two administrative domains. Typically a firewall will be
deployed between 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.</t>
<t>Note that the effectiveness of firewalls remains controversial. While
network managers often insist on deploying firewalls as they impose a
boundary, others point out that their value as a security solution is
debatable. This is because most attacks come from behind the firewall.
In addition, firewalls do not protect against application layer attacks
such as viruses carried in email. Thus as a security solution firewalls
are justified as a defense in depth. That is, while an end system must
in the end be responsible for its own security, a firewall can inhibit
or prevent certain kinds of attacks, for example the consumption of CPU
time on a critical server.</t>
<t>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 GRE 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-core-coap" ?>
<?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.1195" ?>
<?rfc include="reference.RFC.5905" ?>
<?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.5546" ?>
<?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.5681" ?>
<?rfc include="reference.RFC.2588" ?>
<?rfc include="reference.RFC.2608" ?>
<?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.5750" ?>
<?rfc include="reference.RFC.5751" ?>
<?rfc include="reference.RFC.3853" ?>
<?rfc include="reference.RFC.5740" ?>
<?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.4340" ?>
<?rfc include="reference.RFC.4347" ?>
<?rfc include="reference.RFC.4364" ?>
<?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.4741" ?>
<?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" ?>
<?rfc include="reference.I-D.arkko-ipv6-transition-guidelines" ?>
<?rfc include="reference.I-D.ietf-behave-address-format" ?>
<?rfc include="reference.I-D.ietf-behave-dns64" ?>
<?rfc include="reference.I-D.ietf-behave-v6v4-framework" ?>
<?rfc include="reference.I-D.ietf-behave-v6v4-xlate" ?>
<?rfc include="reference.I-D.ietf-behave-v6v4-xlate-stateful" ?>
<?rfc include="reference.I-D.ietf-manet-dymo" ?>
<?rfc include="reference.I-D.ietf-roll-rpl" ?>
<?rfc include="reference.RFC.5569" ?>
<?rfc include="reference.I-D.cheshire-dnsext-dns-sd" ?>
<?rfc include="reference.I-D.cheshire-dnsext-multicastdns" ?>
<?rfc include="reference.RFC.1058" ?>
<?rfc include="reference.RFC.1157" ?>
<?rfc include="reference.RFC.2616" ?>
<?rfc include="reference.RFC.3561" ?>
<?rfc include="reference.RFC.3626" ?>
<?rfc include="reference.RFC.4213" ?>
<?rfc include="reference.RFC.4760" ?>
<?rfc include="reference.RFC.5838" ?>
<?rfc include="reference.RFC.3569" ?>
<?rfc include="reference.RFC.3973" ?>
<?rfc include="reference.RFC.4601" ?>
<?rfc include="reference.RFC.4608" ?>
<?rfc include="reference.RFC.5785" ?>
<?rfc include="reference.RFC.5796" ?>
<?rfc include="reference.RFC.5216" ?>
<reference anchor="IEEE802.1X">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks - Port
based Network Access Control</title>
<author>
<organization>Institute of Electrical and Electronics
Engineers</organization>
</author>
<date month="February" year="2010" />
</front>
<seriesInfo name="IEEE" value="Standard 802.1X-2010" />
</reference>
<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" />
<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>
<!-- LocalWords: Cisco ttcol SCTP DCCP IETF RFCs internet SNMP HTTP MPLS SVCs
-->
<!-- LocalWords: connectionless GMPLS untappable IPsec DNSSEC NetConf DHCP
-->
<!-- LocalWords: DOCSIS IKEv decryptor autoconfiguration ICMP OSPF unicast
-->
<!-- LocalWords: multicast NACK SRMP ICMPv LoWPAN DHCPv autoconfigured SEcure
-->
<!-- LocalWords: Autoconfiguation RIPng OSPFv CLNS AODV DYMO OLSR MLDv MBPS
-->
<!-- LocalWords: GBPS HDLC PPPoE SONET DCCP's Roadmap TCP's CSNET Fuzzball
-->
<!-- LocalWords: codecs NATs UA's iCal Google iCalendar Interoperability iTIP
-->
<!-- LocalWords: iMIP PSTN ISDN traceroute TransitRail CENIC fred Cisco's
-->
<!-- LocalWords: Internets UCSB middleware ISPs aport LSPs IANA Yourtchenko
-->
<!-- LocalWords: Ashok Narayanan Volz Lonvick McGrew Hemant Singh Meylor Vint
-->
<!-- LocalWords: Salowey Julien Abeille Magnus Westerlund Murtaza Droms iSCSI
-->
<!-- LocalWords: Toerless Eckert MULPIv Arcnet VGAnylan decapsulator VPNs
-->
<!-- LocalWords: IETF's stateful reassembly Zigbee HANs BANs FANs hostnames
-->
<!-- LocalWords: CoAP RESTful URIs
-->
| PAFTECH AB 2003-2026 | 2026-04-23 19:34:23 |