Rfc6272 en Es

Internet Engineering Task Force (IETF) F.
Baker,
Petición de Comentarios: 6272 D. Meyer
Categoría: Informativo Cisco Systems
ISSN: 2070-1721 de junio de 2011
Protocolos de Internet para la red inteligente
Abstracto
Esta nota se identifican los protocolos de infraestructura clave de protocolos de Internet para
su uso en la red inteligente. El público objetivo son aquellas personas que buscan orientación
sobre cómo construir un perfil de Internet Protocol Suite apropiado para la red inteligente. En la
práctica, tal perfil consistiría en seleccionar lo que se necesita para el despliegue de redes
inteligentes de la imagen que se presenta aquí.
Condición de este memo
Este documento no es una especificación de normas de Internet; que se publica con fines
informativos.
Este documento es un producto de la Internet Engineering Task Force (IETF). Representa el

consenso de la comunidad IETF. Ha recibido opinión pública y ha sido aprobado para su
publicación por el Grupo de Dirección de Ingeniería de Internet (IESG). No todos los
documentos aprobados por el IESG son un candidato para cualquier nivel de estándar de
Internet; ver
La sección 2 del RFC 5741 .
Información sobre el estado actual de este documento, cualquier errata, y cómo proporcionar
retroalimentación sobre el mismo puede obtenerse en
http://www.rfc-editor.org/info/rfc6272 .
Aviso de copyright
Copyright (C) 2011 IETF Trust y las personas identificadas como los autores del documento.
Todos los derechos reservados.
Este documento está sujeto a BCP 78 y Legal de la IETF Trust

Disposiciones relativas a los documentos IETF ( http://trustee.ietf.org/license-info
) vigente a la fecha de
publicación de este documento. Por favor revise cuidadosamente estos documentos, ya que describen
sus derechos y restricciones con respecto a este documento. Componentes Código extrae de este
documento debe incluir texto de la Licencia BSD simplificado como se describe en la sección 4.e de las
Disposiciones Legales de fideicomiso y se proporciona sin garantía, como se describe en la Licencia
BSD simplificado.
Baker & Meyer informativo [Página 1]

RFC 6272 Protocolos de Internet para la red inteligente de junio de 2011
Tabla de contenido
1 . Introducción . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 . El conjunto de protocolos de Internet. . . . . . . . . . . . . . . . . 6
2.1 . Capas de protocolo de Internet. . . . . . . . . . . . . . . . . 6
2.1.1 . Solicitud . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 . Transporte . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 . Red . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3.1 . Protocolo de Internet . . . . . . . . . . . . . . . . 9
2.1.3.2 . Las redes de capa inferior. . . . . . . . . . . . . . . 9
2.1.4 . Capas de medios de comunicación: físico y de enlace. . . . . . . . . . . 9
2.2 . Temas de seguridad . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 . Seguridad de la capa física y de enlace de datos. . . . . . . . 10
2.2.2 . Red, Transporte y Seguridad de capa de aplicación. . 11
2.3 . Infraestructura de red . . . . . . . . . . . . . . . . . . 13
2.3.1 . Sistema de nombres de dominio (DNS). . . . . . . . . . . . . . . 13
2.3.2 . Administración de redes . . . . . . . . . . . . . . . . . . 13
3 . Protocolos específicos. . . . . . . . . . . . . . . . . . . . . . 14
3.1 . Caja de herramientas de seguridad. . . . . . . . . . . . . . . . . . . . . 14
3.1.1. Autenticación, autorización y contabilidad (AAA). 14
3.1.2 . Red de Seguridad de la capa. . . . . . . . . . . . . . . . 15
3.1.3 . Transport Layer Security . . . . . . . . . . . . . . . dieciséis
3.1.4 . Aplicación de Seguridad de nivel. . . . . . . . . . . . . . 17

3.1.5 . Cubierta segura . . . . . . . . . . . . . . . . . . . . . 18
3.1.6 . Infraestructuras de gestión de claves. . . . . . . . . . . . 18
3.1.6.1 . PKIX. . . . . . . . . . . . . . . . . . . . . . . 18
3.1.6.2 . Kerberos. . . . . . . . . . . . . . . . . . . . . 19
3.2 . Capa de red . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1 . Consejos IPv4 / IPv6 Convivencia. . . . . . . . . . . . . 19
3.2.1.1 . La coexistencia de doble pila. . . . . . . . . . . . . . 19
3.2.1.2 . Mecanismo de túnel. . . . . . . . . . . . . . . 20
3.2.1.3 . La traducción entre IPv4 e IPv6 Networks. . . . 20
3.2.2 . Protocolo de Internet versión 4. . . . . . . . . . . . . 21
3.2.2.1 . Dirección IPv4 de distribución y asignación. . . . . . 22
3.2.2.2 . IPv4 Unicast de enrutamiento. . . . . . . . . . . . . . . 22
3.2.2.3 . IPv4 reenvío de multidifusión y enrutamiento. . . . . . 22
3.2.3 . Protocolo de Internet versión 6. . . . . . . . . . . . . 23
3.2.3.1 . Asignación de direcciones IPv6 y asignación. . . . . . 23
3.2.3.2 . Enrutamiento IPv6. . . . . . . . . . . . . . . . . . . 24
3.2.4 . Enrutamiento de IPv4 e IPv6. . . . . . . . . . . . . . 24
3.2.4.1 . Protocolo de información de enrutamiento . . . . . . . . . . . 24
3.2.4.2 . Open Shortest Path First. . . . . . . . . . . . . 24
3.2.4.3 . Sistema Intermedio ISO a Sistema Intermedio. . 25
3.2.4.4 . Border Gateway Protocol. . . . . . . . . . . . . 25
3.2.4.5 . Dinámica MANET On-Demand (DYMO) de enrutamiento. . . . . . 25
3.2.4.6 . Enlace optimizado protocolo de enrutamiento de estado. . . . . . 26
3.2.4.7 . Enrutamiento de baja potencia y con pérdidas Redes. . . . . 26

3.2.5 . IPv6 reenvío de multidifusión y enrutamiento. . . . . . . . 27

3.2.5.1 . Independiente del protocolo de enrutamiento multicast. . . . . . 27
3.2.6. La adaptación a las redes de capa inferior y protocolos de capa de enlace.
..................... 28
3.3 . Capa de transporte . . . . . . . . . . . . . . . . . . . . . 28
3.3.1 . User Datagram Protocol (UDP). . . . . . . . . . . . . 28
3.3.2 . Protocolo de Control de Transmisión (TCP). . . . . . . . . 29
3.3.3 . Stream Control Transmission Protocol (SCTP). . . . . 29
3.3.4 . Datagramas de Protocolo de Control de Congestión (DCCP). . . . . 30
3.4 . Infraestructura. . . . . . . . . . . . . . . . . . . . . . 30
3.4.1 . Sistema de nombres de dominio . . . . . . . . . . . . . . . . . . 30
3.4.2 . Configuración dinámica de host. . . . . . . . . . . . . . 31
3.4.3 . Tiempo red. . . . . . . . . . . . . . . . . . . . . 31
3.5 . Administración de redes . . . . . . . . . . . . . . . . . . . . 31
3.5.1 . Simple Network Management Protocol (SNMP). . . . . . 31
3.5.2 . Configuración de red (NETCONF) Protocolo. . . . . . . 32
3.6 . Servicio y Detección de recursos. . . . . . . . . . . . . . 33
3.6.1 . Descubrimiento de servicios. . . . . . . . . . . . . . . . . . 33
3.6.2 . Descubrimiento de recursos. . . . . . . . . . . . . . . . . . 33
3.7 . Otras aplicaciones . . . . . . . . . . . . . . . . . . . . 34
3.7.1 . Protocolo de Iniciacion de Sesion . . . . . . . . . . . . . 34
3.7.2 . Extensible Messaging and Presence Protocol. . . . . . 35
3.7.3 . Calendarios. . . . . . . . . . . . . . . . . . . . . 35
4 . Una visión simplificada de la arquitectura de negocios. . . . . . . . 35
5 . Consideraciones de Seguridad . . . . . . . . . . . . . . . . . . . 40
6 . Agradecimientos. . . . . . . . . . . . . . . . . . . . . . . 40
7 . Referencias. . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1 . Referencias normativas . . . . . . . . . . . . . . . . . . . 40
7.2 . Referencias informativas. . . . . . . . . . . . . . . . . . 41
Apéndice A . Ejemplo: infraestructura de medición avanzada. . . . . . 58
A.1 . Cómo estructurar una red. . . . . . . . . . . . . . . . 59
A.1.1 . HAN enrutamiento. . . . . . . . . . . . . . . . . . . . . 62
A.1.2 . Seguridad HAN. . . . . . . . . . . . . . . . . . . . . 62
A.2 . Modelo 1: IAM con dominios separados. . . . . . . . . . . 64
A.3 . Modelo 2: IAM con Barrio acceso al hogar. . . . sesenta y cinco
A.4 . Modelo 3: Collector es un router IP. . . . . . . . . . . . 66

1 . Introducción
Este documento proporciona diseñadores de redes inteligentes con consejos sobre cómo mejor "perfil" de
protocolos de Internet (IPS) para su uso en redes inteligentes. Proporciona una visión general del IPS y los
protocolos de infraestructura clave que son fundamentales en la integración de dispositivos de red
inteligente en una infraestructura basada en IP.
En palabras de Wikipedia [ Red inteligente ]:
Una red inteligente es una forma de red eléctrica que utiliza la tecnología digital. Una red inteligente suministra
electricidad de los proveedores a los consumidores que utilizan las comunicaciones digitales de dos vías para
controlar electrodomésticos en los hogares de los consumidores; Esto ahorra energía, reduce los costes y
aumenta la fiabilidad y la transparencia. Esto se superpone con la red eléctrica ordinaria con un sistema de
información y medición neta, que incluye medidores inteligentes. Las redes inteligentes están siendo
promovidos por muchos gobiernos como una forma de hacer frente a la independencia energética, los
problemas del calentamiento y la capacidad de recuperación de emergencia globales.
Una red inteligente se hace posible mediante la aplicación de dispositivos de detección, medición y
control con comunicaciones de dos vías a la producción de electricidad, transmisión, distribución y
piezas de consumo de la red eléctrica que se comunican información sobre la rejilla condición a los
usuarios del sistema, operadores y dispositivos automatizados, por lo que es posible responder
dinámicamente a los cambios en la rejilla condición.
Una red inteligente incluye un sistema de control inteligente que realiza un seguimiento de toda la
electricidad que fluye en el sistema. También tiene la capacidad de integración de la electricidad renovable,
como la solar y eólica. Cuando la energía es menos costosa que el usuario puede permitir que la red
inteligente para encender electrodomésticos seleccionados, tales como lavadoras o procesos de fabricación
que se pueden ejecutar en horas arbitrarias. En las horas punta que podría apagar los aparatos
seleccionados para reducir la demanda.
Otros nombres para una red inteligente (o de propuestas similares) incluyen inteligente red
eléctrica o potencia, redes inteligentes (o IntelliGrid), futureGrid, y la más moderna red
interconectada y intraGrid.
Esa descripción se centra en las implicaciones de la tecnología de redes inteligentes en el hogar

de un consumidor. De hecho, las tecnologías de comunicaciones de datos de diversos tipos se
utilizan en toda la red, para controlar y mantener la generación de energía, transmisión y
distribución, así como las operaciones y la gestión de la red. Uno puede ver la red inteligente
como una colección de redes de computadoras interconectadas que conecta y atiende las
necesidades de las compañías eléctricas públicas y privadas y sus clientes.

En el momento de escribir estas líneas, no existe un documento único que se puede describir como que
comprende un estándar internacionalmente aceptado para la red inteligente; esto es, en parte, el problema de
ser abordado en su desarrollo. Las aproximaciones más cercanas son probablemente Modelo Conceptual de la
cuadrícula del Grupo de Interoperabilidad inteligente [
Modelo ] Y los documentos
que comprende [ IEC61850 ].
El protocolos de Internet (IPS) ofrece opciones para numerosos componentes

arquitectónicos. Por ejemplo, el IPS ofrece varias opciones para la función de transporte
tradicional entre dos sistemas: el Protocolo de Control de Transmisión (TCP) [
RFC0793 ], El Stream Control
Protocolo de Transmisión (SCTP) [ RFC4960 ], Y la congestión de datagramas
Protocolo de control (DCCP) [ RFC4340 ]. Otra opción es seleccionar una
encapsulación como el Protocolo de datagramas de usuario (UDP) [Usuario RFC0768 ],
que esencialmente permite que una aplicación para implementar su propio servicio de
transporte. En la práctica, un diseñador escogerá un protocolo de transporte que sea
apropiado para el problema a resolver.
El IPS está estandarizado por la Internet Engineering Task Force (IETF). protocolos IETF están
documentados en la Petición de comentarios (RFC). Varios RFC se han escrito que describe
cómo debe implementarse el IPS. Éstas incluyen:
o Requisitos para hosts de Internet - Niveles de Comunicación [ RFC1122 ],
o Requisitos para hosts de Internet - Aplicación y soporte [

RFC1123 ],
o Requisitos para IP versión 4 [Routers RFC1812 ], Y
Requisitos o IPv6 del nodo [ RFC4294 ].
En el momento de escribir estas líneas, RFC 4294 está en proceso de ser

actualizado, en [ IPv6-NODO-REQ ].
Este documento tiene por objeto proporcionar Smart Grid arquitectos y diseñadores con un
compendio de RFC relevantes (y en cierta medida, borradores de Internet), y está organizada
como una lista comentada de RFC. Para tal fin, el resto del documento se organiza de la
siguiente manera:
o Sección 2 describe la arquitectura de Internet y su conjunto de protocolos.
o Seccion 3 esboza un conjunto de protocolos que pueden ser útiles en el despliegue de redes
inteligentes. No es exhaustiva.
o Por último, Sección 4 ofrece una visión general de la empresa

arquitectura plasmada en el diseño y despliegue de la IPS.

2 . La suite de protocolo de Internet
Antes de enumerar la lista de protocolos de Internet correspondientes a la Red Inteligente,

se discute la arquitectura en capas de la IPS, las funciones de las distintas capas y sus
protocolos asociados.
2.1 . Capas de protocolo de Internet
Mientras que la arquitectura de Internet utiliza las definiciones y un lenguaje similar al lenguaje
utilizado por la interconexión de sistema abierto ISO (ISO-OSI) modelo de referencia (Figura 1), que
en realidad es anterior a modelo. Como resultado, hay una cierta asimetría en la terminología. Por
ejemplo, el modelo ISO-OSI utiliza "sistema final", mientras que la arquitectura de Internet utiliza
"host". Del mismo modo, un "sistema intermedio" en el modelo ISO-OSI se denomina una "puerta de
enlace a Internet" o "router" en la jerga de Internet. A pesar de estas diferencias, los conceptos
fundamentales son básicamente los mismos.
+ --------------------+
| Capa de aplicación |
+ --------------------+
| Capa de Presentación |
+ --------------------+
| capa de sesión |
+ --------------------+
| Capa de transporte |
+ --------------------+
| Capa de red |
+ --------------------+
| Capa de enlace de datos |
+ --------------------+
| Capa fisica |
+ --------------------+
Figura 1: El modelo de referencia ISO OSI
La estructura del modelo de referencia de Internet se muestra en la Figura 2.

+ ---------------------------------+
| Aplicación |
| + --------------------------- + | |
| Protocolo de Aplicaciones ||
| + ---------- + ---------------- + | |
| codificación | Control de Sesión | | | +
---------- + ---------------- + |
+ ---------------------------------+
| Transporte |
| + --------------------------- + | |
| Capa de transporte ||
| + --------------------------- + |
+ ---------------------------------+
| Red |
| + --------------------------- + | |
| protocolo de Internet ||
| + --------------------------- + | |
| Más bajas capas de red ||
| + --------------------------- + |
+ ---------------------------------+
Capas de medios | |
| + --------------------------- + | |
| Capa de enlace de datos ||
| + --------------------------- + | |
| Capa fisica ||
| + --------------------------- + |
+ ---------------------------------+
Figura 2: El Modelo de Referencia Internet
2.1.1 . Solicitud
En el modelo de Internet, la aplicación, capas de presentación y de sesión se comprime en

una sola entidad llamada "la aplicación". Por ejemplo, el Simple Network Management
Protocol (SNMP) [ RFC3411 ]
describe una aplicación que codifica sus datos en un perfil de ASN.1 y se involucra en una sesión para
gestionar un elemento de red. El punto aquí es que en Internet, la distinción entre estas capas existe
pero no está resaltado. Además, tenga en cuenta que en la Figura 2, estas funciones no son
necesariamente limpiamente capas: el hecho de que un protocolo de aplicación codifica sus datos de
alguna manera y que gestiona las sesiones de alguna manera, no implica una jerarquía entre esos
procesos. Por el contrario, considera que la aplicación de codificación, gestión de sesiones, y una
variedad de otros servicios como un conjunto de herramientas que utiliza al hacer su trabajo.

2.1.2 . Transporte
El término "transporte" es quizás uno de los conceptos más confusos en la arquitectura de

comunicación, en gran medida porque la gente con diversos antecedentes utilizan para referirse a "la
capa debajo de la que estoy interesado en que recibe mis datos a mi pares" . Por ejemplo, los
ingenieros de redes ópticas se refieren a la fibra óptica y la electrónica asociada como "el
transporte", mientras que los diseñadores web hacen referencia al Protocolo de transferencia de
hipertexto (HTTP) [
RFC2616 ] (Una capa de aplicación
protocolo) como "el transporte".
En la pila de protocolos de Internet, el "transporte" es la capa de protocolo más baja que viaja de
extremo a extremo no modificado, y es responsable de los servicios de entrega de datos de
extremo a extremo. En el Internet, la capa de transporte es la capa por encima de la capa de red.
Los protocolos de capa de transporte tienen un único requisito mínimo: la capacidad de multiplexar
varias aplicaciones en una sola dirección IP. UDP [
RFC0768 ], TCP
[ RFC0793 ], DCCP [ RFC4340 ], SCTP [ RFC4960 ], Y la norma [ RFC5740 ] Cada lograr esto usando un par de números de
puerto, uno para el emisor y otro para el receptor. Un número de puerto identifica una instancia de aplicación, lo que podría
ser un "oyente" en general que los compañeros o clientes pueden abrir sesiones, o un corresponsal específico con un
"oyente" tales. La identificación de sesión en un datagrama IP a menudo se llama el "cinco-tupla", y consta de los IP de
origen y destino direcciones, la fuente y puertos de destino, y un identificador para el protocolo de transporte en uso.
Además, las responsabilidades de un protocolo de capa de transporte específico típicamente incluyen la

entrega de datos (ya sea como una corriente de mensajes o una corriente de bytes) en una secuencia se
indica con las expectativas expresadas con respecto a velocidad de suministro y la pérdida. Por ejemplo, TCP
reducirá su tasa en respuesta a la pérdida, como un disparador de control de congestión, mientras que DCCP
acepta un cierto nivel de pérdida si es necesario para mantener la puntualidad.
2.1.3 . Red
La función principal de la capa de red es identificar un destino remoto y entregar datos a la

misma. En las redes orientadas a la conexión, tales como conmutación Multi-Protocol
Label (MPLS) [ RFC3031 ] o
Modo de Transferencia Asíncrona (ATM), una trayectoria está configurado una vez, y los datos se
entregan a través de él. En redes sin conexión, como Ethernet e IP, los datos se entregan como
datagramas. Cada datagrama contiene tanto la red de origen y destino de direcciones de la capa,
y la red es responsable de la entrega. En el conjunto de protocolos de Internet, el protocolo de
Internet es la red que ejecuta un extremo al otro. Se puede encapsularse sobre otras tecnologías
LAN y WAN, incluyendo tanto las redes IP y redes de otros tipos.

2.1.3.1 . protocolo de Internet
IPv4 e IPv6, cada uno de los cuales se llama el Protocolo de Internet, son sin conexión (
"datagramas") arquitecturas. Están diseñados como elementos comunes que los elementos de red
de interconexión a través de una red de redes de capa inferior. Además del servicio básico de
identificación de origen y el destino de un datagrama, que ofrecen servicios a los fragmentos y volver
a montar los datagramas cuando sea necesario, ayudar en el diagnóstico de fallas en la red, y llevan
la información adicional necesaria en casos especiales.
La capa de Internet proporciona una red de abstracción de red uniforme que oculta las
diferencias entre las diversas tecnologías de red. Esta es la capa que permite diversas
redes, tales como Ethernet,
802.15.4, etc., para ser combinados en una red IP uniforme. Nuevas tecnologías de red pueden
ser introducidos en el protocolo IP Suite de la definición de cómo se lleva a IP sobre esas
tecnologías, dejando a las otras capas de la IPS y las aplicaciones que utilizan los protocolos sin
cambios.
2.1.3.2 . Las redes de capa inferior
La capa de red se puede subdividir de forma recursiva como sea necesario. Esto puede lograrse
por un túnel, en el que un datagrama IP se encapsula en otro encabezado IP para la entrega a un
desencapsulador. IP se realiza con frecuencia en redes privadas virtuales (VPN) a través de la
Internet pública utilizando tecnologías de túneles, tales como el modo de túnel de IPsec, IP-en-IP, y
la encapsulación de ruta genérica (GRE) [
RFC2784 ].
Además, IP también se realiza con frecuencia en redes de circuitos tales como MPLS [
RFC4364 ], GMPLS, y ATM. Por último, IP también se traslada
redes inalámbricas (IEEE 802.11, 802.15.4, o 802.16) y cambiaron de Ethernet (IEEE 802.3)
redes.
2.1.4 . Capas de medios de comunicación: Física y Enlace
En la capa más baja de la arquitectura IP, los datos se codifica en mensajes y transmitidos a través de los
medios de comunicación físico. Mientras que el IETF especifica algoritmos para llevar a IPv4 e IPv6 tipos
distintos medios de comunicación, es raro que en realidad define los medios de comunicación - que
felizmente utiliza las especificaciones de IEEE, ITU y otras fuentes.
2.2 . Temas de seguridad
Mientras se quejan acerca de la seguridad de Internet es muy popular, es importante distinguir entre los ataques a
los protocolos y los ataques a los usuarios (por ejemplo, el phishing). Los ataques contra los usuarios son en gran
parte independiente de los detalles de protocolo, lo que refleja los problemas de diseño de interfaz de usuario o
problemas de educación, y están fuera del alcance de este documento. Los problemas de seguridad con los
protocolos de Internet son en su alcance, por supuesto, y puede

a menudo se ha mitigado mediante funciones de seguridad existentes ya especificados para el protocolo, o

mediante el aprovechamiento de los servicios de seguridad ofrecidos por otros protocolos de IETF. Vea la
Evaluación de la Seguridad del Protocolo de Control de Transmisión (TCP) [
TCP-SEC ] Y la Seguridad
Evaluación del Protocolo de Internet versión 4 [ IP-SEC ] para más
información sobre cuestiones de TCP y el IPv4, respectivamente.
Estas soluciones, sin embargo, necesitan conseguir desplegado también. El camino hacia la
implantación generalizada a veces puede ser doloroso ya menudo múltiples partes interesadas deben
tomar acciones. La experiencia ha demostrado que esto lleva algún tiempo, y muy a menudo sólo ocurre
cuando los incentivos son lo suficientemente altos en relación con los costos.
Por otra parte, es importante hacer hincapié en que las normas disponibles son importantes, pero la
gama de problemas de seguridad es más grande que una norma que falta; muchos problemas de
seguridad son el resultado de errores de ejecución y el resultado de ciertas opciones de despliegue. Si
bien estos son fuera del ámbito de la elaboración de normas, que desempeñan un papel importante en
la seguridad del sistema en su conjunto. La seguridad tiene que ser integrado en todo el proceso.
El IETF toma en serio la seguridad en el diseño de sus protocolos y arquitecturas; todas las
especificaciones IETF tiene que tener una sección Consideraciones de Seguridad para
documentar las amenazas y contramedidas de seguridad que ofrece.
RFC 3552 [ RFC3552 ] Proporciona recomendaciones sobre
escribir una sección Consideraciones tales Seguridad. También se describe el modelo clásico
amenaza a la seguridad de Internet y las listas de objetivos comunes de seguridad.
En pocas palabras, la seguridad tiene que ser integrado en cada protocolo, la extensión de
protocolo y, en consecuencia, cada capa de la pila de protocolo para ser útil. Ilustramos esto
también en este documento con referencias a discusiones adicionales de seguridad. Nuestra
experiencia ha demostrado que se trata de la seguridad en el último momento no conduce al
resultado deseado.
La discusión de las amenazas de seguridad y los mecanismos de seguridad disponibles pretende ilustrar
algunos de los aspectos de diseño que aparecen comúnmente.
2.2.1 . Seguridad de la capa física y de enlace de datos
En las capas física y de enlace de datos, amenazas por lo general se centran en ataques físicos
en la red - los efectos de retroexcavadoras, deterioro del medio físico, y diversos tipos de ruido
ambiental. redes basada en radio están sujetas a la señal de desvanecimiento debido a la
distancia, la interferencia, y los factores ambientales; se observa ampliamente que IEEE
802.15.4 redes frecuentemente colocan una placa de tierra de metal entre el medidor y el
dispositivo que gestiona. La fibra fue en un

tiempo de desplegado, ya que se creía que era untappable; ya que hemos aprendido a utilizar por
flexión de la fibra y la recolección incidental luz, y hemos aprendido sobre retroexcavadoras. Como
resultado, algunas instalaciones encierran cable de fibra óptica en una funda a presión, tanto para
identificar rápidamente la ubicación de un corte y para que sea más difícil de aprovechar.
Si bien existen comportamientos de protocolo que pueden detectar ciertas clases de defectos físicos, tales
como intercambios de mantenimiento de conexión, seguridad física generalmente no se considera que sea un
problema de protocolo.
Para las tecnologías de transmisión inalámbrica, las escuchas en las tramas transmitidas
también suele ser una preocupación. Además, esas redes que operan pueden querer
asegurarse de que el acceso a su infraestructura está restringido a aquellos que están
autenticado y autorizado (normalmente llamado 'autenticación de acceso a la red'). Este
procedimiento se ofrece a menudo por las primitivas de seguridad en la capa de enlace de
datos.
2.2.2 . Red, transporte y aplicación de seguridad de capa
En las capas de red, transporte y aplicación, es común para exigir unos requisitos de seguridad
básicos, comúnmente conocida como la CIA (confidencialidad, integridad y disponibilidad):
1. Confidencialidad: Proteger los datos transmitidos desde la divulgación no autorizada (es decir,
mantener los fisgones de aprender lo que se transmite). Por ejemplo, para la confianza en las
aplicaciones de comercio electrónico, transacciones de tarjetas de crédito se intercambian cifran
entre el navegador web y un servidor Web.
2. Integridad: proteger contra cambios no autorizados en los intercambios, incluyendo tanto el

cambio intencional o destrucción y el cambio accidental o pérdida, asegurándose de que los
cambios en los intercambios son detectables. Tiene dos partes: una para los datos y otra
para los compañeros.
* Compañeros necesitan para verificar que la información que aparece a ser de un compañero de
confianza es realmente de esa pares. Normalmente, esto se llama 'origen autenticación de datos'.
* Los compañeros tienen que validar que el contenido de los datos intercambiados es sin modificar. El
término que se utiliza típicamente de esta propiedad es 'integridad de los datos'.
3. Disponibilidad: Asegúrese de que el recurso es accesible mediante la mitigación de

ataques de denegación de servicio.

A esto le sumamos la autenticidad, la cual requiere que los compañeros de comunicación

demuestran que en realidad son quienes dicen que son el uno al otro (es decir, la autenticación
mutua). Esto generalmente significa saber "que" el interlocutor es, y que demuestren la posesión
de un "secreto", como parte de la interacción protocolo de seguridad.
Los tres ejemplos siguientes tienen por objeto ilustrar estos requisitos de seguridad.
Un ataque común contra una sesión TCP es bombardear la sesión con mensajes de
restablecimiento. Otros ataques contra TCP incluyen el ataque "SYN flooding", en el que un
atacante intenta agotar la memoria del objetivo mediante la creación de estado TCP. En particular,
el atacante intenta agotar la memoria de la diana mediante la apertura de un gran número de
conexiones TCP únicos, cada uno de los cuales está representado por un bloque de control de
transmisión (TCB). El ataque tiene éxito si el atacante puede hacer que el objetivo llenar su
memoria con los TCB.
Varios mecanismos se han desarrollado para hacer frente a este tipo de ataques de denegación de servicio.
Uno de ellos, "SYN cookies", los retrasos establecimiento del estado en el lado del servidor para una fase
posterior en el intercambio de protocolo. Otro mecanismo, específicamente el ataque de reposición antes
citada, proporciona servicios de autenticación en sí mismo TCP para asegurar que se restablece falsos son
rechazados.
Otro enfoque sería que ofrecen ya la protección de seguridad en una capa inferior, como
IPsec (véase sección 3.1.2 ) O TLS (véase
sección 3.1.3 ) , de manera que un host puede identificar los mensajes legítimos y
descartar los otros, así mitigar cualquier daño que pueda haber sido causado por el ataque.
Otro ataque común implica el acceso no autorizado a los recursos. Por ejemplo, una parte no autorizada
podría tratar de conectarse a una red. Para protegerse contra este tipo de ataque, un proveedor de
servicios de Internet (ISP) requiere normalmente la red de autenticación de acceso de nuevos huéspedes
que solicitan el acceso a la red ya Internet antes de ofrecer el acceso. Este intercambio típicamente
requiere la autenticación de la entidad y una verificación en los ISPs de base de datos de servicios de
fondo para determinar si existen correspondientes registros de abonados y siguen siendo válidos (por
ejemplo, suscripción activa y créditos suficientes).
De la discusión anterior, se establece un canal de comunicación seguro es claramente un concepto importante que
se utiliza con frecuencia para mitigar una serie de ataques. Por desgracia, al centrarse sólo en la seguridad del canal
puede no ser suficiente para una tarea determinada. modelos de amenazas han evolucionado e incluso algunos de
los puntos finales de comunicación no pueden ser considerados totalmente digno de confianza, es decir, los
compañeros incluso de confianza pueden actuar maliciosamente.
Baker & Meyer informativo [Pagina 12]

Además, muchos protocolos son más sofisticados en su interacción protocolo e implican más
de dos partes en el intercambio de protocolo. Muchos de los protocolos de capa de aplicación,
tales como correo electrónico, mensajería instantánea, voz sobre IP, y aplicaciones basadas
en presencia, entran en esta categoría. Con esta clase de protocolos, datos seguros, como los
registros DNS, y comunicaciones seguras con el middleware, servidores intermedios y
aplicaciones de apoyo deben tenerse en cuenta, así como la seguridad de la comunicación
directa. Un tratamiento detallado de las amenazas de seguridad y requisitos de estos
protocolos múltiples partes está más allá de esta especificación, pero el lector interesado
puede consultar los ejemplos antes mencionados para una ilustración de qué mecanismos
técnicos se han investigado y propuesto en el pasado.
2.3 . Infraestructura de red
Si bien los protocolos siguientes no son críticos para el diseño de un sistema específico, son
importantes a la ejecución de una red, y como tal se estudian aquí.
2.3.1 . Sistema de nombres de dominio (DNS)
La función principal DNS es traducir nombres a direcciones IP numéricas. Si bien esto no es

crítico para operar una red, ciertas funciones se hacen mucho más fácil si las direcciones
numéricas pueden ser sustituidos por nombres mnemotécnicos. Esto facilita la renumeración de
las redes y en general mejora la manejabilidad y capacidad de servicio de la red. DNS tiene un
conjunto de extensiones de seguridad DNSSEC llamada, que se puede utilizar para proporcionar
autenticación fuerte criptográfica para el DNS. DNS y DNSSEC se discuten en
sección 3.4.1 .
2.3.2 . Administración de redes
gestión de la red ha demostrado ser un problema difícil. Como tal, se han propuesto varias
soluciones, implementado y desplegado. Cada solución tiene sus defensores, todos los cuales
tienen argumentos sólidos para sus puntos de vista. El IETF tiene dos soluciones de gestión de red
principales para el funcionamiento del dispositivo: SNMP, que es ASN.1 codificada y se utiliza
principalmente para el control de las variables del sistema, y NETCONF [ RFC4741 ], Que es
codificada en XML y se utiliza principalmente para la configuración del dispositivo.
Otro aspecto de la gestión de red es el aprovisionamiento inicial y la configuración de

anfitriones, que se discute en sección 3.4.2 . Nota
que la red inteligente implementaciones pueden requerir autenticación de la identidad y autorización (así
como otra aprovisionamiento y configuración) que puede no estar dentro del alcance de DHCP o
descubrimiento de vecinos. Mientras que el conjunto de protocolos IP tiene un soporte limitado para la
compra segura

aprovisionamiento y configuración, estos problemas han sido resueltos utilizando protocolos IP en las
especificaciones, tales como DOCSIS 3.0 [ SP-MULPIv3.0 ].
3 . Protocolos específicos
En esta sección, después de haber establecido brevemente la arquitectura IP y algunos de los

problemas que la arquitectura trata de abordar, se introduce protocolos específicos que podrían ser
apropiadas para diferentes casos de uso inteligente de cuadrícula. Los casos de uso deben analizarse
junto con la privacidad, autenticación, autorización y contabilidad (AAA), las dimensiones de transporte,
y la solución de red. Las siguientes secciones proporcionan una guía para dicho análisis.
3.1 . Caja de herramientas de seguridad
Como se ha indicado, una consideración clave en las soluciones de seguridad es un buen análisis de la
amenaza junto con estrategias de mitigación apropiadas en cada capa. El IETF ha desarrollado con el
tiempo una serie de bloques de construcción para la seguridad basada en la observación de que los
protocolos menudo demandar servicios de seguridad similares. Las siguientes subsecciones describen
algunos de esos bloques de construcción de seguridad de uso común. La reutilización de ellos ofrece
varias ventajas, tales como la disponibilidad de código fuente abierto, la experiencia con los sistemas
existentes, un número de extensiones que se han desarrollado, y la confianza de que las tecnologías
enumeradas han sido revisados y analizados por una serie de expertos en seguridad.
Es importante destacar que, además de las herramientas de seguridad mencionadas, todos los
protocolos a menudo viene con las consideraciones de seguridad adicionales, a menudo únicos
que son específicos para el dominio en el que opera el protocolo. Muchos protocolos incluyen
características específicamente diseñadas para mitigar estos riesgos específicos del protocolo.
En otros casos, las consideraciones de seguridad identificarán servicios relevantes para la
seguridad que se requieren de otras capas de red para lograr niveles adecuados de seguridad.
3.1.1 . Autenticación, autorización y contabilidad (AAA)
Mientras que el término AAA suena genérica y aplicable a todo tipo de protocolos de
seguridad, ha sido, en el IETF, que se utiliza en relación con la red de autenticación de
acceso y está asociado con el radio ([
RFC2865 ]) Y el protocolo Diámetro ([ RFC3588 ], [ DIME-BASE ]) En
especial.
El procedimiento de autenticación para el acceso a la red tiene como objetivo hacer frente a la tarea de
verificar que un compañero está autenticado y autorizado antes de acceder a un recurso en particular (a
menudo conectividad a Internet). Por lo general, la arquitectura de autenticación para el acceso a la red
se compone de los siguientes componentes básicos: el Extensible

Protocolo de autenticación (EAP [ RFC4017 ]) Como un recipiente para encapsular

métodos EAP, de un método de EAP (como una forma específica para realizar la autenticación
criptográfica y de intercambio de claves, tal como se describe en
RFC 5216 [ RFC5216 ] y RFC 5433 [ RFC5433 ]), Un protocolo que transporta cargas útiles de EAP entre el host
extremo y una entidad del lado del servidor (tal como un servidor de acceso de red), y una manera de transportar
cargas útiles de EAP a back-end infraestructura de servidor (potencialmente en un escenario de dominios cruzados)
para proporcionar la funcionalidad de autorización y contabilidad. La última parte es proporcionada por radio y
diámetro. Para llevar cargas útiles de EAP entre el host extremo y un servidor de acceso a la red, se han
estandarizado diferentes mecanismos, tales como el Protocolo para llevar autenticación para el acceso a la red
(PANA) [
RFC5191 ] Y IEEE 802.1X [ IEEE802.1X ].

Para el acceso a redes remotas, tales como las redes de empresa, la capacidad de utilizar
EAP dentro de IKEv2 [ RFC5996 ] también ha sido
desarrollado.
Más recientemente, la misma arquitectura con EAP y radio / diámetro está siendo reutilizado para
protocolos de capa de aplicación. Más detalles acerca de esta variante arquitectónica se pueden encontrar
en [ ABFAB-ARCH ].
3.1.2 . Seguridad de la capa de red
seguridad IP, como se describe en [ RFC4301 ], Se dirige a la seguridad en el IP

capa, proporcionada a través del uso de una combinación de mecanismos de seguridad criptográficos y de
protocolo. Ofrece un conjunto de servicios de seguridad para el tráfico en la capa IP, tanto en el entorno
IPv4 e IPv6. El conjunto de servicios de seguridad ofrecidos incluye control de acceso, integridad sin
conexión, autenticación del origen de los datos, la detección y el rechazo de las repeticiones (una forma de
integridad de la secuencia parcial), confidencialidad (a través de cifrado), y confidencialidad limitada del flujo
de tráfico. Estos servicios se proporcionan en la capa IP, ofreciendo una protección de una manera
estándar para todos los protocolos que pueden ser transportados a través de IP (IP incluyendo sí mismo).
La arquitectura prevé una división entre el consume bastante tiempo (a) la autenticación y el paso
protocolo de intercambio de claves que también establece una asociación de seguridad (una
estructura de datos con keying parámetros de material y de seguridad) y (b) la protección real del
tráfico de datos.
Para el primero paso, la versión de protocolo Internet Key Exchange 2 (IKEv2 [

RFC5996 ]) Es la más reciente edición del estandarizada
protocolo. IKE negocia cada uno de los algoritmos criptográficos que se utilizan para proteger los
datos de forma independiente, algo así como la selección de artículos a la carta.
Para la protección de datos real, se han utilizado históricamente dos tipos de protocolos,
a saber, la cabecera de autenticación IP (AH)

[RFC4302] y la carga útil de seguridad de encapsulación (ESP) [ RFC4303 ].

Los dos difieren en los servicios de seguridad que ofrecen; la distinción más importante es que ofrece
protección de la confidencialidad ESP mientras AH no lo hace. Desde ESP también puede proporcionar
servicios de autenticación, la mayoría de los desarrollos recientes de protocolos que hacen uso de IPsec
sólo especifican el uso de ESP y AH no utilizan.
Además de estos mecanismos de protocolo de línea base de un número de extensiones se han

desarrollado para IKEv2 (por ejemplo, una extensión para llevar a cabo EAP-sólo la autenticación
[ RFC5998 ]) Y ya que la arquitectura
soporta el tratamiento flexible de los algoritmos criptográficos un número de ellos han sido
especificadas (por ejemplo, [ RFC4307 ] Para IKEv2, y [ RFC4835 ]
para AH y ESP).
3.1.3 . Transport Layer Security
v1.2 Transport Layer Security [ RFC5246 ] Son servicios de seguridad que

proteger los datos por encima de la capa de transporte. El protocolo permite que las aplicaciones
cliente / servidor se comuniquen de una manera que está diseñada para impedir la escucha,
manipulación o falsificación de mensajes. TLS es el protocolo de aplicación independiente.
TLS se compone de dos capas: el protocolo TLS Record y el protocolo TLS Handshake. El
protocolo TLS Record proporciona seguridad de conexión que tiene dos propiedades básicas:
(a) protección de la confidencialidad y protección (b) integridad.
El protocolo TLS apretón de manos permite que el servidor y el cliente para autenticarse entre
sí y que negocien un algoritmo de cifrado y las claves de cifrado antes de que el protocolo de
aplicación transmite o recibe su primer byte de datos. Los parámetros negociados y el material
de claves derivada se utiliza entonces por el protocolo TLS Record para realizar su trabajo.
A diferencia de IKEv2 / IPsec, TLS negocia estos parámetros criptográficos en las suites, los
llamados 'paquetes de cifrado. Ejemplos de conjuntos de cifrado que pueden ser negociados con TLS
incluyen criptografía de curva elíptica (ECC) [ RFC4492 ] [ RFC5289 ] [ AES-CCM-ECC ], Camellia [
RFC5932 ], Y la suite
B Perfil [ RFC5430 ]. [ IEC62351-3 ] Esboza el uso de diferentes TLS
conjuntos de cifrado para su uso en la red inteligente. Los mecanismos criptográficos básicos
para la ECC se han documentado en [ RFC6090 ].
TLS debe pasar por un canal de transporte fiable - normalmente TCP. Con el fin de ofrecer los
mismos servicios de seguridad para el tráfico de datagramas no fiable, como UDP, la seguridad de
la capa de datagramas de Transporte (DTLS [ RFC4347 ] [ DTLS ]) fue desarrollado.

3.1.4 . Aplicación de Seguridad de nivel
En ciertos casos, los mecanismos de seguridad independientes de capa de aplicación que se

describen en las subsecciones anteriores no son suficientes para hacer frente a todas las amenazas
identificadas. Para este fin, un número de primitivas de seguridad son, además, disponible en la capa
de aplicación en la que la semántica de la aplicación puede ser considerado.
Nos centraremos nuestra descripción de unos mecanismos que se utilizan comúnmente en todo
el Internet.
Sintaxis de mensajes criptográficos (CMS [ RFC5652 ]) Es una encapsulación

la sintaxis para firmar, resumir, autenticar o cifrar el contenido del mensaje arbitraria. También
permite a los atributos arbitrarios, como el tiempo de firma, que se firmará junto con el contenido
del mensaje, y prevé otros atributos como refrendos a ser asociados con una firma. El CMS puede
soportar una variedad de arquitecturas de gestión de claves basada en certificados, como el
definido por la PKIX (Public Key Infrastructure utilizando X.509) grupo de trabajo [
RFC5280 ]. los
CMS ha sido aprovechado para suministrar servicios de seguridad en una variedad de protocolos, incluyendo
seguro de correo electrónico [ RFC5751 ], gestión de claves [ RFC5958 ]

[ RFC6031 ], y actualizaciones de firmware [ RFC4108 ].
Relacionado trabajo incluye el uso de firmas digitales en documentos XML codificado, que ha sido
estandarizado conjuntamente por el W3C y el IETF [ RFC3275 ]. XML firmado digitalmente es una
buena opción donde las aplicaciones soportan nativamente datos XML codificados, como la
mensajería extensible and Presence Protocol (XMPP).
Más recientemente, el trabajo de la autenticación y autorización delegado menudo exigido por las
aplicaciones Web se han desarrollado con la autenticación Open Web (OAuth) Protocolo [
RFC5849 ] [ OAUTHv2 ]. OAuth es
utilizado por las aplicaciones de terceros para obtener acceso a los recursos protegidos (como la
información sobre el consumo de energía de un hogar específico) sin tener el recurso propietario
Compartir sus credenciales a largo plazo con ese tercero. En OAuth, la aplicación de terceros
solicita acceso a los recursos controlados por el propietario del recurso y alojados en el servidor
de recursos, y se emite un conjunto diferente de credenciales que los del propietario del recurso.
Más específicamente, las aplicaciones de terceros obtengan una señal de acceso durante el
intercambio de protocolo OAuth. Esta señal indica un alcance específico, duración y otros
atributos de acceso. Como resultado, se obtiene de forma segura el acceso al recurso protegido
con el consentimiento del propietario del recurso.

3.1.5 . Cubierta segura
El Secure Shell (SSH) protocolo [ RFC4253 ] Ha sido ampliamente utilizado por

administradores y otros para el acceso remoto seguro, pero también es útil para túneles seguros.
Más recientemente, los protocolos han elegido a la capa en la parte superior de SSH para los
servicios de seguridad del transporte; por ejemplo, el protocolo de gestión de red NETCONF (ver
sección 3.5.2 ) Utiliza SSH como
su principal protocolo de seguridad de las comunicaciones.
3.1.6 . Las infraestructuras de gestión de claves
Todos los protocolos de seguridad mencionados anteriormente dependen de la criptografía para la seguridad, y
por lo tanto requieren alguna forma de gestión de claves. La mayoría de los protocolos de IETF, al menos
nominalmente requieren alguna forma escalable de gestión de claves a ser definidos como obligatorios para
poner en práctica; de hecho, la falta de tales características clave de gestión en el pasado ha sido una razón para
retrasar la aprobación de protocolos. Hay dos esquemas de gestión de claves genéricas que son ampliamente
utilizados por otros protocolos de Internet, PKIX y Kerberos, cada uno de los cuales se describen brevemente a
continuación.
3.1.6.1 . PKIX
Infraestructura de Clave Pública (PKI) se refiere a la clase de gestión de claves que se basa en las
autoridades de certificación (CA) de la emisión de certificados de clave pública para otros titulares clave.
Encadenando de un ancla de confianza (una copia de confianza a nivel local de una clave pública CA) a la
clave pública de algún protocolo de pares, PKI permite la segura unión entre las teclas y los nombres
específicos del protocolo, tales como direcciones de correo electrónico, y por lo tanto permite a los servicios
de seguridad tal como datos y autenticación del mismo nivel, integridad de datos, y confidencialidad (cifrado).
La norma principal de Internet para la PKI es [ RFC5280 ], Que es un perfil de

del formato de certificado de clave pública X.509. Hay una serie de entidades de certificación privados y
comerciales que operan hoy en día proporcionando la capacidad de gestionar y distribuir las claves de forma
segura para todos los protocolos que utilizan certificados de clave pública, por ejemplo, TLS y S / MIME. Además
de la norma de perfil, el grupo de trabajo PKIX ha definido un número de protocolos de gestión (por ejemplo, [
RFC5272 ] Y [ RFC4210 ]), Así como protocolos para

manejo de revocación de certificados de clave pública, como el Online Certificate
Status Protocol (OCSP) [ RFC2560 ].
PKI se percibe generalmente a mejores casos de uso de la manija que abarcan múltiples
dominios independientes en comparación con Kerberos.

3.1.6.2 . Kerberos
El sistema de autenticación Kerberos Red [ RFC4120 ] Se utiliza comúnmente

dentro de las organizaciones para centralizar la autenticación, la autorización y la política en un solo
lugar. Kerberos soporta de forma nativa nombres de usuario y contraseñas como la base de la
autenticación. Con criptografía de clave pública para la autenticación inicial en Kerberos (PKINIT) [ RFC4556
], Kerberos es compatible con certificado o autenticación basada en clave pública. Esto puede
proporcionar una ventaja mediante la concentración de la política sobre la validación de certificados y
la cartografía de los certificados a cuentas de usuario en un lugar. A través de la GSS-API [
RFC1964 ] [ RFC2743 ]
[ RFC4121 ], Kerberos se puede utilizar para administrar la autenticación para la mayoría de aplicaciones.
Mientras que Kerberos funciona mejor dentro de las organizaciones y empresas, que tiene instalaciones que
autoricen la autenticación para ser compartido entre los dominios administrativos.
3.2 . Capa de red
El IPS especifica dos protocolos de capa de red: IPv4 y IPv6. Las siguientes secciones
describen los mecanismos de coexistencia y de transición de la IETF para IPv4 y IPv6.
Tenga en cuenta que el 3 de febrero de 2011, se agotó conjunto de direcciones IPv4 de la IANA (el
conjunto de direcciones IPv4 disponibles, sin asignar), y se espera que los de Internet Registradores
Regionales (RIR) piscinas gratuitas a agotarse durante el próximo año, si no antes . El IETF, la IANA, y
los RIR recomiendan que las nuevas implementaciones utilizan IPv6, y que las infraestructuras IPv4 ser
apoyados a través de los mecanismos descritos en
sección 3.2.1 .
3.2.1 . Consejos IPv4 / IPv6 Coexistencia
El IETF ha especificado una variedad de mecanismos diseñados para facilitar IPv4 / IPv6
coexistencia. El IETF recomienda realmente relativamente pocos de ellos: el consejo actual para
los operadores de red se encuentra en Directrices para el uso Mecanismos de Transición IPv6 [
RFC6180 ]. los
pensamientos en ese documento se replican aquí.
3.2.1.1 . Dual Stack Coexistencia
El enfoque más simple es la convivencia
o proporcionar una red de rutas que IPv4 e IPv6,
o Asegurar que los servidores y sus aplicaciones de manera similar soportan ambos protocolos, y

o requieren que todos los nuevos sistemas y aplicaciones adquiridas o mejoradas de

soporte ambos protocolos.
El resultado neto es que con el tiempo todos los sistemas se vuelven protocolo agnóstico, y que con el
tiempo el mantenimiento del apoyo IPv4 se convierte en una decisión de negocios. Este enfoque se
describe en los mecanismos básicos de transición para hosts y enrutadores IPv6 [
RFC4213 ].
3.2.1.2 . Mecanismo de túnel
En aquellos lugares en la red que admiten sólo IPv4, el método más sencillo y fiable de la
convivencia es proporcionar conectividad virtual a través de túneles o encapsulados. Temprano
en el despliegue de IPv6, esto se hace a menudo el uso de túneles estáticos. Un enfoque más
dinámico se documenta en IPv6 Despliegue rápido sobre Infraestructuras de IPv4 (6rd) [
RFC5569 ].
3.2.1.3 . La traducción entre IPv4 e IPv6 Redes
En aquellos casos en que un sólo IPv4 anfitrión desea comunicarse con un host sólo IPv6 (o
viceversa), una necesidad de traducción de protocolo puede ser indicada. A primera vista, la
traducción protocolo puede parecer trivial; en una inspección más profunda, resulta que la traducción
de protocolo puede ser complicado.
El enfoque más fiable de traducción de protocolo es proporcionar proxies o puertas de enlace de capa
de aplicación, que permiten de forma nativa conexiones de aplicación a aplicación utilizando ambos
protocolos y puede utilizar según sea apropiado. Por ejemplo, un proxy web puede utilizar ambos
protocolos y como resultado permitir que un sólo IPv4 sistema para ejecutar HTTP a través de un sólo
IPv6 red o en un servidor Web que implementa solamente IPv6. Desde este enfoque es un servicio
de un servidor de protocolo agnóstico, no es el tema de la normalización por el IETF.
Para aquellas aplicaciones en las que está indicado traducción capa de red, la IETF ha
diseñado un mecanismo de traducción, que se describe en los siguientes documentos:
Marco o para IPv4 / IPv6 Traducción [ RFC6144 ]
o IPv6 Direccionamiento de IPv4 / IPv6 traductores [ RFC6052 ]
extensiones o DNS [ RFC6147 ]
o IP / ICMP Traducción algoritmo [ RFC6145 ]
o Traducción de clientes IPv6 a los servidores IPv4 [ RFC6146 ]

Al igual que con la traducción de direcciones de red IPv4 / IPv4, la traducción entre IPv4 e IPv6 ha
limitado aplicabilidad al mundo real para un protocolo de aplicación que lleva a direcciones IP en su
capacidad de carga y espera que dichas direcciones sean significativos para el cliente y el servidor.
Sin embargo, para aquellos protocolos que no lo hacen, la traducción de protocolo puede
proporcionar una extensión útil red.
Traducción basada en la red prevé dos tipos de servicios: sin estado (y, por tanto, escalable y de
carga compartible) de traducción entre las direcciones IPv4 e IPv6 que incorporan una dirección
IPv4 en ellos, y de traducción con estado similar a la traducción de IPv4 / IPv4 entre las
direcciones IPv4. El modo sin estado es sencillo de implementar, pero debido a la incrustación,
requiere direcciones IPv4 a ser asignado a una por lo demás sólo IPv6 a la red, y es sobre todo útil
para los servidores IPv4accessible implementados en la red IPv6. El modo de estado permite a los
clientes en la red IPv6 para acceder a los servidores de la red IPv4, pero no proporciona dicho
servicio para los clientes acceso IPv4 IPv6 compañeros o servidores con direcciones generales;
tiene la ventaja de que no requiere que una única dirección IPv4 puede incrustar en la dirección
IPv6 de los ejércitos que utilizan este mecanismo.
Por último, tenga en cuenta que algunas redes de sitios son sólo IPv6, mientras que algunas redes
de tránsito son sólo IPv4. En estos casos, puede ser necesario hacer un túnel IPv6 sobre IPv4 o
traducir entre IPv6 e IPv4.
3.2.2 . Protocolo de Internet versión 4
IPv4 [ RFC0791 ] Y el Protocolo de mensajes de control de Internet (ICMP) [ RFC0792 ]

Comprender la capa de red IPv4. IPv4 proporciona la entrega no fiable de los datagramas.
IPv4 también proporciona para la fragmentación y reensamblaje de largos datagramas para la

transmisión a través de redes con pequeñas unidades de transmisión máxima (MTU). La MTU es el
tamaño del paquete más grande que se puede entregar a través de la red. Además, el IPS
proporciona ICMP [ RFC0792 ], Que es un protocolo separado que permite a la red para informar
errores y otros problemas a los hosts que se originan datagramas problemáticos.
IPv4 apoyado originalmente un tipo experimental de campo de servicio que identifica ocho
niveles de prioridad operativa de estilo después de los requisitos de la telefonía militar, además
de tres y más tarde de cuatro banderas de bits que OSI IS-IS para IPv4 (IS-IS) [
RFC1195 ] Y OSPF Versión 2
[ RFC2328 ] Interpretado como el tráfico de control; este tráfico de control tiene la seguridad de que
no se cayó cuando la cola o bajo recibo, incluso si se está eliminando el resto del tráfico. Estos bits
de control resultaron ser menos útiles que los diseñadores habían esperado. Fueron reemplazados
por la arquitectura de servicios diferenciados [
RFC2474 ] [ RFC2475 ], cual

contiene un punto de código de seis bits que se utiliza para seleccionar un algoritmo (un "comportamiento por
salto") que se aplicará a los datagramas. El IETF también ha producido un conjunto de Directrices de
configuración para clases de servicio DiffServ [ RFC4594 ], Que describe un conjunto de clases de servicio
que pueden ser útiles a un operador de red.
3.2.2.1 . IPv4 y adjudicación de direcciones Asignación
Las direcciones IPv4 se administrativamente asignados, por lo general utilizando métodos automatizados,
utilizando el Dynamic Host Configuration Protocol (DHCP) [ RFC2131 ]. En la mayoría de los tipos de
interfaces, sistemas vecinos identifican las direcciones de los demás utilizando el protocolo de resolución de
direcciones (ARP) [ RFC0826 ].
3.2.2.2 . IPv4 Unicast de enrutamiento
Enrutamiento de Internet IPv4 se logra mediante el enrutamiento de aplicaciones que intercambian

información de conectividad y construir bases de datos de enrutamiento de destino semi-estáticas.
Si un datagrama se dirige a una dirección de destino, la dirección se busca en la base de datos de
enrutamiento, y el ( "más largo") prefijo más específico encontró que la contiene se utiliza para
identificar el router del siguiente salto o el sistema final a la cual será entregado. Esto no se aplica
por lo general en los ejércitos, aunque puede ser; una gran cantidad normalmente envía los
datagramas a un router en su red local, y el router lleva a cabo la intención.
IETF especifica los protocolos de enrutamiento incluyen RIP Versión 2 [ RFC2453 ], OSI
IS-IS para IPv4 [ RFC1195 ], OSPF Versión 2 [ RFC2328 ], Y BGP-4
[ RFC4271 ]. existe investigación activa en el móvil de encaminamiento ad hoc y otros paradigmas de
enrutamiento; estos resultado en nuevos protocolos y paradigmas de reenvío modificados.
3.2.2.3 . IPv4 reenvío de multidifusión y enrutamiento
IPv4 se especificó originalmente como un unicast (punto a punto) de protocolo, y se

extendió a apoyar multicast en [ RFC1112 ]. Este utiliza el
Internet Group Management Protocol [ RFC3376 ] [ RFC4604 ] para permitir
aplicaciones que se unen a grupos de multidifusión, y para la mayoría de aplicaciones utiliza Origen
Específicas Multicast [ RFC4607 ] Para el encaminamiento y la entrega de
mensajes de multidifusión.
Un experimento llevado a cabo en IPv4 que no es parte de la arquitectura básica de

Internet, pero puede ser interesante en la red inteligente es el desarrollo de la llamada
"Multicast fiable". Esto es "llamado" porque no es "fiable" en el sentido estricto de la
palabra - es quizás mejor descrito como "una mayor fiabilidad". Una mejor red de esfuerzo,
por definición, puede perder tráfico, duplicarlo o reordenar, algo tan cierto para
multidifusión como para unicast. La investigación en

La tecnología "fiable Multicast" tiene la intención de mejorar la probabilidad de entrega de tráfico de

multidifusión.
En esa investigación, el IETF impone directrices [ RFC2357 ] sobre el

comunidad de investigación respecto a lo que era deseable. importantes resultados de la
investigación que incluyen una serie de documentos y varios protocolos de propiedad, incluyendo
algunos que se han utilizado en apoyo de las operaciones comerciales. RFCs en el área incluyen
el uso de Forward Error Correction (FEC) en Multicast fiable [
RFC3453 ], lo negativo-
acuse de recibo (NACK) -oriented Multicast fiable (NORM) Protocolo [ RFC5740 ], Y el Protocolo
de multidifusión fiable selectiva (SRMP) [ RFC4410 ].
3.2.3 . Protocolo de Internet versión 6
IPv6 [ RFC2460 ], Con el "v6" control de Internet Protocolo de mensajes de [ RFC4443 ], Que
constituye la próxima generación de protocolo de Internet. IPv6 proporciona para la transmisión de
datagramas desde la fuente a los hosts de destino, que se identifican por las direcciones de longitud
fija.
IPv6 también proporciona para la fragmentación y reensamblaje de datagramas de largo por el host de
origen, si es necesario, para la transmisión a través de redes "pequeño de paquetes". ICMPv6, que es
un protocolo implementado por separado junto con IPv6, permite a la red para informar errores y otros
problemas a los hosts que se originan datagramas problemáticos.
IPv6 adoptó la Arquitectura de Servicios Diferenciados [ RFC2474 ]

[ RFC2475 ], Que contiene un punto de código de seis bits que se utiliza para seleccionar un algoritmo (un
"comportamiento por salto") que deben aplicarse para el datagrama.
El IPv6 a través de bajo consumo personal inalámbrica redes de área RFC [ RFC4919 ]
y el formato de compresión para IPv6 Datagramas en 6LoWPAN Redes documento [
6LoWPAN-HC ] Direcciones IPv6 de compresión de cabecera y la subred
arquitectura en al menos algunas redes de sensores, y puede ser apropiado a la infraestructura de
red inteligente avanzada de medición u otros dominios de sensores.
3.2.3.1 . Adjudicación de direcciones IPv6 y Asignación
Una dirección IPv6 [ RFC4291 ] Puede ser asignado administrativamente usando

DHCPv6 [ RFC3315 ] De una manera similar a la forma en las direcciones IPv4 son. Además, las
direcciones IPv6 también se pueden configuran automáticamente. Autoconfiguración permite varios
modelos de gestión de red que puede ser ventajoso en diferentes casos de uso. procedimientos de
autoconfiguración se definen en [
RFC4862 ] Y [ RFC4941 ]. vecinos IPv6
identificar las direcciones de los demás utilizando descubrimiento de vecinos (ND) [ RFC4861 ].
Secure Vecino Descubrimiento (SEND) [ RFC3971 ] Puede ser usado para
asegurar estas operaciones.

3.2.3.2 . enrutamiento IPv6
Enrutamiento de Internet IPv6 se lleva a cabo mediante el enrutamiento de aplicaciones que

intercambian información de conectividad y construir bases de datos de enrutamiento de destino
semi-estáticas. Si un datagrama se dirige a una dirección de destino, la dirección se busca en la
base de datos de enrutamiento, y el ( "más largo") prefijo más específico encontró que la contiene
se utiliza para identificar el router del siguiente salto o el sistema final a la cual será entregado.
Enrutamiento no se implementa generalmente en anfitriones (aunque puede ser); Generalmente, un
host envía los datagramas a un router en su red local, y el router lleva a cabo la intención.
protocolos de enrutamiento especificados-IETF incluyen RIP para IPv6 [ RFC2080 ],

IS-IS para IPv6 [ RFC5308 ], OSPF para IPv6 [ RFC5340 ], Y BGP-4 para IPv6
[ RFC2545 ]. existe investigación activa en el móvil de encaminamiento ad hoc, el enrutamiento en redes de baja
potencia (sensores y las redes inteligentes), y otros paradigmas de enrutamiento; estos resultado en nuevos
protocolos y paradigmas de reenvío modificados.
3.2.4 . Enrutamiento de IPv4 e IPv6
3.2.4.1 . Protocolo de información de enrutamiento
El protocolo de enrutamiento prototípico utilizado en Internet ha sido probablemente el Protocolo de

información de enrutamiento [ RFC1058 ]. Las personas que lo utilizan
hoy en día tienden a desplegar RIPng para IPv6 [ RFC2080 ] Y RIP Versión 2
[ RFC2453 ]. Brevemente, RIP es un protocolo de enrutamiento de vector de distancia que se basa en
una variante distribuida del ampliamente conocido algoritmo Bellman-Ford. En los protocolos de
enrutamiento vector distancia, cada router anuncia el contenido de su tabla de enrutamiento a los
routers vecinos, que integran los resultados con sus tablas de rutas y volver a anunciar a los demás.
Se ha caracterizado como "encaminamiento por rumor", y sufre muchos de los males que
encontramos en el chisme humana - propagación de información obsoleta o incorrecta en ciertos
escenarios de fallo, y estar en los casos que no responden a los cambios en la topología. [
RFC1058 ] proporciona
orientación a los diseñadores de algoritmos para mitigar estos problemas.
3.2.4.2 . Open Shortest Path First
El primero (OSPF) protocolo de enrutamiento ruta libre más corta es uno de los protocolos
más utilizados en Internet. OSPF se basa en primer lugar bien conocido (SPF) algoritmo de la
ruta más corta de Dijkstra. Se implementa como OSPF Versión 2 [
RFC2328 ] Para IPv4, OSPF para IPv6
[ RFC5340 ] Para IPv6, y el Apoyo de Familias de direcciones en OSPFv3 [ RFC5838 ] para permitir
[ RFC5340 ] Encaminamiento IPv4 e IPv6.
La ventaja de cualquier protocolo basado en SPF (es decir, OSPF e IS-IS) es principalmente
que cada router en la red construye su vista de la

la red de conocimiento de primera mano en lugar de los "chismes" que los protocolos de vector de
distancia se propagan. Como tal, la topología se cambia de forma rápida y fácilmente con sólo
anunciar el cambio. La desventaja de los protocolos basados en SPF es que cada router debe
almacenar una declaración en primera persona de la conectividad de cada router en el dominio.
3.2.4.3 . Sistema Intermedio ISO a Sistema Intermedio
El Sistema Intermedio a Sistema Intermedio protocolo de enrutamiento (IS-IS) es uno de los

protocolos más ampliamente utilizados en la Internet. IS-IS también se basa en el algoritmo SPF de
Dijkstra. Se especificó originalmente como ISO DP 10589 para el encaminamiento de servicio de red
sin conexión (CLNS), y se extendió para el encaminamiento en TCP / IP y los entornos de doble [
RFC1195 ], Y más recientemente para el encaminamiento de IPv6
[ RFC5308 ].
Al igual que con OSPF, los aspectos positivos de cualquier protocolo basado en SPF y
específicamente IS-IS son principalmente que la red se describe como un entramado de routers con
conectividad a subredes y hosts aislados. Es topología se cambia de forma rápida y fácilmente con
sólo anunciar el cambio, sin los problemas de "encaminamiento por rumor", ya que cada equipo
dentro del dominio de enrutamiento tiene una declaración en primera persona de la conectividad de
cada router en el dominio. Los negativos son un corolario: cada router debe almacenar una
declaración en primera persona de la conectividad de cada router en el dominio.
3.2.4.4 . Border Gateway Protocol
El Border Gateway Protocol (BGP) [ RFC4271 ] Se utiliza ampliamente en la

IPv4 de Internet para intercambiar rutas entre entidades administrativas -Servicio de proveedores,
sus compañeros, sus redes de aguas arriba, y sus clientes - mientras que la aplicación de políticas
específicas. Las extensiones multiprotocolo [
RFC4760 ] Para permitir BGP BGP para llevar a IPv6 entre dominios
enrutamiento [ RFC2545 ], La accesibilidad de información de multidifusión y VPN
información, entre otros.
Consideraciones que se aplican con BGP se ocupan de la flexibilidad y la complejidad de

las políticas que deben ser definidos. La flexibilidad es una buena cosa; en una red que
no está a cargo de los profesionales, la complejidad es gravosa.
3.2.4.5 . Dinámica MANET On-Demand (DYMO) Enrutamiento
El grupo de trabajo ad hoc móvil del IETF ha desarrollado, entre otros protocolos, Ad hoc
On-Demand de vector de distancia (AODV) Routing [ RFC3561 ].
Este protocolo capturado las mentes de algunos en la industria de dispositivos embebidos, pero
experimentó problemas en las redes inalámbricas, tales como

802.15.4 y el modo Ad Hoc de 802.11. Como resultado, es en el proceso de ser actualizado en la

dinámica MANET bajo demanda (DYMO) de protocolo de enrutamiento de [
DYMO ].
AODV y DYMO son esencialmente los protocolos de enrutamiento reactivos diseñados para redes
móviles ad hoc, y utilizables en otras formas de redes ad hoc. Ellos proporcionan conectividad entre un
dispositivo dentro de una subred distribuida y unos dispositivos (incluyendo tal vez una puerta de
enlace o router a otra subred) sin el seguimiento conectividad a otros dispositivos. En esencia, el
enrutamiento se calcula y se descubrió en la necesidad, y un host o router sólo necesita mantener las
rutas que actualmente trabajan y son necesarios.
3.2.4.6 . Optimized Link State Routing
El protocolo optimizado Link State Routing (OLSR) [ RFC3626 ] es un

protocolo de encaminamiento proactivo diseñado para redes móviles ad hoc, y se puede utilizar en
otras formas de redes ad hoc. Se proporciona conectividad arbitraria entre sistemas dentro de una
subred distribuida. Al igual que con los protocolos diseñados para redes cableadas, enrutamiento se
calcula cada vez que se detectan cambios, y se mantiene en las tablas de cada router. El conjunto
de nodos que funcionan como routers dentro de la subred, sin embargo, son bastante fluido, y
depende de esta topología momentánea de la subred.
3.2.4.7 . Enrutamiento de baja potencia y con pérdidas Redes
El Protocolo de Enrutamiento IPv6 de la energía baja y redes con pérdida (RPL) [ RPL ] Es un
protocolo de encaminamiento reactivo diseñado para su uso en redes con recursos limitados.
Requisitos para redes con recursos limitados se definen en [
RFC5548 ], [ RFC5673 ], [ RFC5826 ] Y [ RFC5867 ].
Brevemente, una red constreñido se compone de nodos que:
O se construyen con limitado poder de procesamiento y memoria, y algunas veces la energía cuando
se opera con baterías.
o están interconectados a través de una interfaz de red-velocidad de datos baja y son potencialmente
vulnerables a la inestabilidad de comunicación y las tasas de entrega de paquetes bajos.
o potencialmente tener una mezcla de papeles tales como ser capaz de actuar como un anfitrión (es
decir, la generación de tráfico) y / o un router (es decir, tanto de reenvío y la generación de tráfico
RPL).

3.2.5 . IPv6 reenvío de multidifusión y enrutamiento
IPv6 especifica tanto el intercambio de datagramas unicast y multicast. Este utiliza el

Protocolo Multicast Listener Discovery (MLDv2) [ RFC2710 ]
[ RFC3590 ] [ RFC3810 ] [ RFC4604 ] Para habilitar aplicaciones para unirse a grupos de multidifusión, y para
la mayoría de aplicaciones utiliza Origen Específicas Multicast [
RFC4607 ] Para el encaminamiento y la entrega de mensajes de multidifusión.
Los mecanismos experimental desarrollado para multidifusión fiable en IPv4, discuten en

sección 3.2.2.3 , se puede utilizar en IPv6 también.
3.2.5.1 . Independiente del protocolo de enrutamiento multicast
Un protocolo de enrutamiento de multidifusión tiene dos funciones básicas: la construcción del árbol de
distribución multicast y el reenvío de tráfico de multidifusión. los protocolos de enrutamiento de multidifusión
contienen generalmente un plano de control para la construcción de árboles de distribución, y un plano de
reenvío que utiliza el árbol de distribución al reenviar el tráfico de multidifusión.
El modelo de multidifusión funciona de la siguiente manera: anfitriones expresan su interés en

recibir el tráfico multicast de una fuente mediante el envío de un mensaje de Adhesión a su
enrutador de primer salto. Enrutador que a su vez envía un mensaje de Ingreso aguas arriba hacia
la raíz del árbol, injertando el router (nodo hoja) en el árbol de la distribución para el grupo. Los
datos se entregan por el árbol hacia los nodos hoja, que lo remitirá a la red local para la entrega.
El modelo de multidifusión inicial desplegado en la Internet se conoce como Cualquier-Source

Multicast (ASM). En el modelo ASM, cualquier host podría enviar a un grupo de multidifusión y la
inter-dominio fue difícil. Los protocolos como Protocolo Multicast Independiente - Modo Denso
(PIM-DM): Especificación del protocolo (revisado) [
RFC3973 ] Y el Protocolo Independent Multicast
- Sparse Mode (PIM-SM): Especificación del protocolo (revisado) [ RFC4601 ]
fueron diseñados para el modelo ASM.
Muchas implementaciones de multidifusión modernos usan Origen Específicas Multicast (PIMSSM) [

RFC3569 ] [RFC4608]. En el modelo de SSM, un huésped expresa interés en un "canal", que
se compone de una fuente (S) y un grupo (G). árboles de distribución tienen sus raíces en el host emisor
(llamado "(S, G) del árbol"). Puesto que sólo la fuente S puede enviar en el grupo, SSM tiene capacidad
inherente anti-jamming. Además, multicast inter-dominio se simplifica ya que encontrar el canal (S, G)
están interesados en recibir es la responsabilidad de los receptores (en lugar de las redes). Esto implica
que SSM requiere algún tipo de servicio de directorio para que los receptores puedan encontrar los
canales (S, G).

3.2.6 . La adaptación a las redes de capa inferior y protocolos de capa de enlace
En general, la arquitectura de capas de Internet permite a la IPS para funcionar sobre

cualquier arquitectura adecuada la capa dos. La capacidad de cambiar el enlace o capa
física sin tener que reconsiderar la capa de red, transporta, o aplicaciones ha sido un gran
beneficio en el Internet.
Ejemplos de tecnología de adaptación de capa de enlace incluyen:
Ethernet / IEEE 802.3: IPv4 ha ejecutar en cada entorno de capa de enlace que utiliza la
cabecera de Ethernet (es decir, 10 y 100 MBPS cable Ethernet, 1 y 10 Gbps cable
Ethernet, y las diferentes versiones de IEEE 802.11) utilizando [
RFC0894 ]. IPv6 hace lo mismo
utilizando [ RFC2464 ].
PPP: El IETF ha definido un protocolo de línea de serie, el Protocolo de Punto a Punto (PPP) [
RFC1661 ], Que utiliza alto nivel de control de enlace de datos
encuadre (bit-síncrono o asíncrono byte). La especificación adaptación IPv4 es
[ RFC1332 ], Y la adaptación IPv6
especificación es [ RFC5072 ]. El uso actual de este protocolo es en
líneas serie tradicionales, intercambios de autenticación en redes DSL utilizando PPP
sobre Ethernet (PPPoE) [ RFC2516 ], Y la digital
Señalización Jerarquía (denominado generalmente como Packet-on-SONET / SDH), utilizando PPP sobre
SONET / SDH [ RFC2615 ].
IEEE 802.15.4: La especificación de la adaptación para la transmisión de IPv6 sobre redes

IEEE 802.15.4 es [ RFC4944 ].
Existen numerosas otras especificaciones de adaptación, incluyendo ATM, Frame Relay, X.25,
otras tecnologías LAN estandarizados y de propiedad, entre otros.
3.3 . Capa de transporte
En esta sección se describe la funcionalidad de la UDP, TCP, SCTP y DCCP. UDP y TCP son mejor
conocidos y más ampliamente utilizados en el Internet hoy en día, mientras que SCTP y DCCP son nuevos
protocolos que fueron construidos para propósitos específicos. Otros protocolos de transporte se pueden
construir cuando sea necesario.
3.3.1 . User Datagram Protocol (UDP)
El User Datagram Protocol [ RFC0768 ] Y el Usuario Ligera

Protocolo de Datagrama [ RFC3828 ] Son propiamente no los protocolos de "transporte" en
el sentido de "un conjunto de reglas que rigen el intercambio o comunicación de datos por vía
electrónica entre dispositivos". Son etiquetas que

proporcionar para la multiplexación de aplicaciones directamente en la capa IP, con

funcionalidad de transporte incrustado en la aplicación.
Muchos diseños de cambio se han construido utilizando UDP, y muchos de ellos no han funcionado. Como
resultado, el uso de UDP realmente debe ser tratado como el diseño de un nuevo transporte. Asesoramiento
sobre el uso de la UDP en nuevas aplicaciones se pueden encontrar en Unicast UDP Directrices de uso
para los diseñadores de aplicaciones [
RFC5405 ].
Datagrama Transport Layer Security [ RFC5238 ] Se puede utilizar para prevenir

escucha, manipulación o falsificación de mensajes para aplicaciones que se ejecutan a través de UDP.
Alternativamente, UDP se puede ejecutar a través de IPsec.
3.3.2 . Protocolo de Control de Transmisión (TCP)
TCP [ RFC0793 ] Es el protocolo de transporte predominante usado en la Internet. Es "fiable",

como el término se utiliza en el diseño de protocolo: se entrega datos a sus pares y
proporciona acuse de recibo al remitente, o muere tratando. Tiene extensiones para Control
de Congestión [ RFC5681 ] Y explícita de congestión Notificación [
RFC3168 ].
La interfaz de usuario para TCP es una interfaz de flujo de bytes - una aplicación que utiliza TCP
podría "escribir" a varias veces sólo para que los datos compactados en un segmento común y
entregados como tal a su igual. Para las interfaces mensaje-stream, ACSE / ROSA utiliza el servicio
de transporte ISO sobre TCP [
RFC1006 ] [RFC2126] en la aplicación.
Transport Layer Security [ RFC5246 ] Se puede utilizar para prevenir

escucha, manipulación o falsificación de mensajes. Alternativamente, TCP puede ejecutar a través de IPsec.
Adicionalmente, [ RFC4987 ] Discute mecanismos similares
al enfoque de "cookie" DCCP de SCTP y de que puedan ser utilizados para asegurar las sesiones TCP contra los
ataques de inundación.
Por último, señalar que el TCP ha sido objeto de investigación y desarrollo en curso desde que
fue escrito. El Plan de trabajo para documentos de especificación TCP [
RFC4614 ] Capta esta historia, y está destinada a ser una
guiar a los desarrolladores actuales y futuras de la zona.
3.3.3 . Protocolo de control de transmisión de flujo (SCTP)
SCTP [ RFC4960 ] Es un protocolo de transporte fiable más reciente que puede ser imaginado como un
contexto TCP similar que contiene múltiples flujos de mensajes separados e independientes (a diferencia
de flujos de bytes de TCP). El diseño de SCTP incluye el comportamiento apropiado para evitar la
congestión y la resistencia a las inundaciones y ataques de máscaras. Como se utiliza una interfaz de
flujo de mensajes, también puede ser más apropiada para el servicio de transporte ISO de utilizar
RFC 1006 / 2126 para activar el octeto de TCP

arroyos en una interfaz de mensajes.

SCTP ofrece varias opciones de entrega. El servicio básico es la entrega secuencial no duplicada de
mensajes dentro de una corriente, para cada flujo en uso. Dado que los flujos son independientes, una
corriente puede hacer una pausa debido al bloqueo de cabeza de línea, mientras que otra corriente en la
misma sesión continúa entregando datos. Además, SCTP proporciona un mecanismo para pasar por el
servicio de entrega secuenciada. mensajes de los usuarios enviados a través de este mecanismo se
entregan al usuario SCTP tan pronto como se reciben.
SCTP implementa un sencillo mecanismo de "cookie" pretende limitar la eficacia de los

ataques de inundación por una autenticación mutua. Esto demuestra que la aplicación está
conectada a la misma por pares, pero no identifica los pares. Mecanismos también existen
para la reconfiguración dinámica de direcciones [
RFC5061 ], Permitiendo a los compañeros para cambiar direcciones
durante la sesión y sin embargo mantener la conectividad. Transport Layer Security [

RFC3436 ] Se puede utilizar para evitar la escucha, manipulación,
o falsificación de mensajes. Alternativamente, SCTP puede ejecutar a través de IPsec.
3.3.4 . Protocolo de Datagrama de control de la congestión (DCCP)
DCCP [ RFC4340 ] Es un protocolo de "poco fiable" transporte (por ejemplo, uno que no garantiza la
entrega de mensajes) que proporciona conexiones de unidifusión bidireccionales de datagramas no
fiables de congestión controlada. DCCP es adecuado para aplicaciones que transfieren bastante
grandes cantidades de datos y que pueden beneficiarse de control sobre el equilibrio entre la
puntualidad y fiabilidad.
DCCP implementa un sencillo mecanismo de "cookie" pretende limitar la eficacia de los ataques de
inundación por una autenticación mutua. Esto demuestra que la aplicación está conectada a la misma por
pares, pero no identifica los pares. Datagrama Transport Layer Security [ RFC5238 ] Se puede utilizar para
impedir la escucha, manipulación o falsificación de mensajes. Alternativamente, DCCP se puede ejecutar a
través de IPsec.
3.4 . Infraestructura
3.4.1 . sistema de nombres de dominio
Con el fin de facilitar la gestión y operaciones de la red, la comunidad de Internet ha

definido el sistema de nombres de dominio (DNS) [ RFC1034 ]
[ RFC1035 ]. Los nombres son jerárquica: un nombre como example.com se encontró registrado en un
registrador .com, y dentro de la red asociada otros nombres como baldur.cincinatti.example.com se
puede definir, con la jerarquía obvia. extensiones de seguridad, que permiten un registro para firmar
los registros contenidos en él y, al hacerlo, demostrar su autenticidad, se definen por el extensiones
de seguridad del DNS [
RFC4033 ]
[ RFC4034 ] [ RFC4035 ].

Los dispositivos también pueden actualizar opcionalmente su propio registro DNS. Por ejemplo, un sensor que
está usando Autoconfiguración dirección sin estado [ RFC4862 ] Para crear una dirección podría querer asociar
con un nombre mediante DNS dinámico de actualización [
RFC2136 ] O Asegurar la actualización dinámica de DNS
[ RFC3007 ].
3.4.2 . Configuración dinámica de host
Como se discutió en sección 3.2.2 , IPv4 asignación de direcciones es generalmente

realizado mediante DHCP [ RFC2131 ]. Por el contrario, sección 3.2.3 puntos
que la asignación de direcciones IPv6 se puede lograr usando cualquiera de autoconfiguración
[ RFC4862 ] [ RFC4941 ] O DHCPv6 [ RFC3315 ]. El mejor
argumento para el uso de la configuración automática de un gran número de sistemas que requieren
poco más que un número aleatorio como una dirección; el argumento para DHCP es el control
administrativo.
Hay otros parámetros que pueden necesitar ser asignada a hosts que requieren configuración
administrativa; Los ejemplos incluyen las direcciones de los servidores DNS, claves para Secure
DNS y servidores de tiempo de red.
3.4.3 . Tiempo de red
El Protocolo de Tiempo de Red fue diseñado originalmente por Dave Mills de la Universidad de Delaware y
CSNET, la aplicación de una medida temporal en el protocolo de enrutamiento de Fuzzball y en general la
coordinación de los experimentos de tiempo. Las versiones actuales del protocolo de tiempo son el
Protocolo de Tiempo de Red [
RFC5905 ].
3.5 . Administración de redes
El IETF ha desarrollado dos protocolos de gestión de red: SNMP y NETCONF. SNMP se discute en
sección 3.5.1 Y es NETCONF
discutido en sección 3.5.2 .
3.5.1 . Simple Network Management Protocol (SNMP)
El Simple Network Management Protocol, especificados originalmente en la década de 1980 y

de haber pasado por varias revisiones, se especifica en varios documentos:
o Una Arquitectura para la Descripción de Simple Network Management Protocol (SNMP Marcos)
Gestión [ RFC3411 ]
o procesamiento de mensajes y el envío [ RFC3412 ]
Utilización de producto o SNMP [ RFC3413 ]

o basada en el usuario Modelo de Seguridad (USM) para SNMP versión 3 [ RFC3414 ]
Modelo de control de acceso basado en Ver o (VACM) [ RFC3415 ]
o la versión 2 del protocolo SNMP Operaciones [ RFC3416 ]
o asignaciones de Transporte [ RFC3417 ]
o Base de Información de Gestión (MIB) [ RFC3418 ]
Proporciona capacidades para las actividades controladas por eventos encuestados y, y por tanto el
seguimiento y la configuración de sistemas en el campo. Históricamente, se ha utilizado
principalmente para el seguimiento de nodos en una red. Los mensajes y sus datos constitutivos se
codifican utilizando un perfil de ASN.1.
3.5.2 . Configuración del protocolo de red (NETCONF)
El Protocolo de configuración NETCONF se especifica en un documento básico, con los

justificantes de la realización por encima de la IPS. Estos documentos incluyen:
o Protocolo de configuración NETCONF [ RFC4741 ]
o Usando el protocolo de configuración NETCONF más de Secure Shell (SSH) [

RFC4742 ]
o El uso de NETCONF sobre el Simple Object Access Protocol (SOAP) [

RFC4743 ]
o Usando el Protocolo NETCONF sobre el protocolo de intercambio de bloques Extensible (BEEP) [

RFC4744 ]
o notificaciones de eventos [NETCONF RFC5277 ]
O NETCONF más Transport Layer Security (TLS) [ RFC5539 ]
o parcial de bloqueo de llamadas a procedimiento remoto (RPC) para NETCONF [ RFC5717 ]
NETCONF fue desarrollado en respuesta a las solicitudes de operador para un protocolo de configuración
común basado en texto ASCII, a diferencia de ASN.1. En esencia, se realiza llamada a procedimiento remoto
codificados en XML (RPC) de datos. En respuesta a los requisitos de red inteligente, no es la consideración de
una variante del protocolo que podría ser utilizado para actividades de gestión de encuestados y eventdriven,
y tanto para la supervisión y configuración de sistemas en el campo.

3.6 . Servicio y Detección de recursos
Servicio y la localización de recursos son algunos de los protocolos más importantes para las redes de
auto-organización de recursos limitados. Estos incluyen varias redes de sensores, así como las redes de
área local de (Hans), área de construcción Networks (BAN), y redes de área de campo (ventiladores)
previstos por los arquitectos de redes inteligentes.
3.6.1 . Descubrimiento de servicio
protocolos de descubrimiento de servicios están diseñados para la configuración automática y detección de

dispositivos y los servicios ofrecidos por los dispositivos descubiertos. En muchos casos de descubrimiento de
servicios se lleva a cabo por los llamados dispositivos "de recursos limitados" (es decir, los que tienen un
poder limitado de procesamiento, la memoria y recursos de poder).
En general, el descubrimiento de servicios se refiere a la resolución y la distribución de los nombres

de host a través de DNS multicast [ Multicast DNS ] y el
la localización automática de servicios de red a través de DHCP ( sección 3.4.2 ) , el
Descubrimiento de servicio DNS (DNS-SD) [ DNS-SD ] (Parte de Bonjour de Apple
tecnología), y el Protocolo de Ubicación de servicio (SLP) [ RFC2608 ].
3.6.2 . Detección de recursos
Detección de recursos se refiere con el descubrimiento de los recursos ofrecidos por puntos finales y es
extremadamente importante en aplicaciones de circuito cerrado de la máquina-tomachine (es decir, los que
no tienen los seres humanos en el bucle). Los objetivos de los protocolos de descubrimiento de recursos
incluyen:
o La simplicidad de la creación y el mantenimiento de los recursos
o semántica comúnmente entendido
o cumplimiento de los estándares existentes y emergentes
o Ámbito Internacional y aplicabilidad
o extensibilidad
o interoperabilidad entre las colecciones y los sistemas de indexación
El protocolo de aplicación restringida (COAP) [ COAP ] esta en desarrollo

en IETF con estos objetivos en mente. En particular, coap está diseñado para su uso en redes de
recursos limitados y para aplicaciones de máquina a máquina, como la energía inteligente y
automatización de edificios. Proporciona un protocolo de transferencia RESTful [
SOSEGADO ], Un recurso integrado
protocolo de descubrimiento, e incluye conceptos web, tales como URIs y tipos de contenido.
Coap proporciona recursos de unidifusión y multidifusión

descubrimiento e incluye filtrar en los atributos de descripciones de recursos. Por último, la

búsqueda de recursos coap también se puede utilizar para descubrir los recursos HTTP.
Para simplificar, COAP hace la suposición de que todos los servidores coap escuchar en el puerto por defecto
COAP o de otra manera se han configurado o descubierto el uso de algún mecanismo de descubrimiento de
servicios generales tales como Descubrimiento de servicio DNS (DNS-SD) [
DNS-SD ].
descubrimiento de recursos en el COAP se logra mediante el uso de los recursos bien conocidos
que describen los enlaces ofrecidos por un servidor COAP. Coap define un URI conocido para el
descubrimiento: "/.well-known/r" [ RFC5785 ]. Por ejemplo, la consulta [GET /.well-known/r] devuelve
una lista de enlaces (que representa los recursos) disponibles desde el servidor coap consultado.
Una consulta como [GET /.well-known/r?n=Voltage] devuelve los recursos con el nombre de tensión.
3.7 . Otras aplicaciones
Hay muchas aplicaciones que dependen de la infraestructura IP, pero no se cree correctamente de
como parte de la infraestructura IP en sí. Estas aplicaciones pueden ser útiles en el contexto de la
red inteligente. Las decisiones tomadas en la construcción de un perfil de Internet del perfil suite
puede afectar la forma en tales aplicaciones podría ser utilizado. Algunos de ellos, de ninguna
manera una lista exhaustiva, se discuten aquí.
3.7.1 . protocolo de Iniciacion de Sesion
El Protocolo de Iniciación de Sesión [ RFC3261 ] [ RFC3265 ] [ RFC3853 ]

[ RFC4320 ] [ RFC4916 ] [ RFC5393 ] [ RFC5621 ] Es un control de capa de aplicación del protocolo
(señalización) para crear, modificar y terminar sesiones multimedia en la Internet, y está destinado a ser más
escalable que H.323. sesiones multimedia pueden ser de voz, video, mensajería instantánea, los datos
compartidos, y / o suscripciones de eventos. SIP se puede ejecutar en la parte superior de TCP, UDP, SCTP o
TLS sobre TCP. SIP es independiente de la capa de transporte, e independiente de la versión / v6 subyacente
IPv4. De hecho, el protocolo de transporte utilizado puede cambiar a medida que el mensaje SIP atraviesa
entidades SIP desde el origen al destino.
sí SIP no elegir si es una sesión de voz o de vídeo, ni identifica las direcciones IP de los
puntos finales reales. El Protocolo de Descripción de Sesión (SDP) [
RFC4566 ] Está destinado para esos fines.
Dentro del SDP, que es transportado por el SIP, códecs son ofrecidos y aceptados (o no), y el
número de puerto y la dirección IP a la que cada punto final quiere recibir su Protocolo de
transporte en tiempo real (RTP) [ RFC3550 ] Se determinan paquetes. La introducción de la
tecnología de dirección de red (NAT) en el perfil, ya sea IPv4 /

IPv4, IPv4 / IPv6 como se describe en sección 3.2.1.3 O IPv6 / IPv6,

aumenta la complejidad de la implementación de SIP / SDP. Esto se discute más en [
RFC2993 ] Y [ RFC5626 ].
3.7.2 . Extensible Messaging and Presence Protocol
El protocolo de mensajería y presencia extensible (XMPP) [ RFC6120 ] es un

protocolo para la transmisión de Extensible Markup Language (XML) elementos con el fin de
intercambiar información estructurada en casi en tiempo real entre dos puntos finales de la red.
Desde XMPP proporciona un marco generalizado, extensible para el intercambio de datos XML, se
ha propuesto como una estructura de la aplicación para el intercambio entre los dispositivos y
sensores embebidos. Actualmente se utiliza para la mensajería instantánea y presencia [
RFC6121 ] Y una amplia variedad de tiempo real

modos de comunicación. Estos incluyen el chat multiusuario, publishsubscribe, alertas y notificaciones, el
descubrimiento de servicios, gestión de sesiones multimedia, configuración de dispositivos, y las
llamadas a procedimientos remotos. XMPP soporta el cifrado de canal usando TLS [
RFC5246 ] y fuerte
de autenticación (incluyendo la autenticación de certificados PKIX) usando SASL [ RFC4422 ].
También hace uso de direcciones compatibles con Unicode y UTF-8 [
RFC3629 ] Intercambio de datos para la internacionalización.
XMPP permite la firma de extremo a extremo y de objetos de cifrado [ RFC3923 ],

el acceso a los objetos nombrados usando Nombres Uniformes de Recursos (URN) [ RFC4854 ],
uso de Internationalized de recursos Identificadores (IRIS) y identificadores uniformes de
recursos (URIs) [ RFC5122 ], Y la presentación de
Notificaciones [ RFC5437 ].
3.7.3 . calendario
calendario de Internet, como se aplica en Apple iCal, Outlook y Microsoft Entourage, y Google
Calendar, se especifica en Internet Calendarios y especificación del objeto Programación Core
(iCalendar) [ RFC5545 ] Y está en proceso de ser actualizado a un esquema XML en iCalendar
representación XML [
xcal ]. Existen varios protocolos de
llevar a los eventos del calendario, incluido el Protocolo de iCalendar independiente del transporte de
Interoperabilidad (iTIP) [ RFC5546 ], El iCalendar Mensaje-
Protocolo de interoperabilidad basada (iMIP) [ RFC6047 ], Y el código abierto
trabajar en el protocolo de publicación Atom [ RFC5023 ].
4 . Una visión simplificada de la Arquitectura de Negocios
La Internet es una red de redes en las que las redes están interconectadas de una manera
específica y son operados de forma independiente. Es importante señalar que la arquitectura
de Internet subyacente no pone restricciones sobre las formas en que las redes están
interconectadas; interconexión es una decisión de negocios. Como tal, la Internet

arquitectura de interconexión puede ser pensado como una "estructura empresarial"

para Internet.
Fundamental para la estructura de negocios de Internet son las redes que proporcionan conectividad con otras redes, llamadas
"redes de tránsito". Estas redes venden servicios de ancho de banda y encaminamiento a granel entre sí y con otras redes como
clientes. Alrededor de la periferia de la red de tránsito son empresas, escuelas y otras redes que proporcionan servicios
directamente a los individuos. Estos por lo general pueden ser divididos en "redes de empresa" y "redes de acceso"; redes
empresariales proporcionan conectividad "libre" a sus propios empleados o miembros, y también les proporcionan un conjunto de
servicios que incluyen el correo electrónico, servicios web, y así sucesivamente. redes de acceso venden conectividad de banda
ancha (DSL, módem por cable, inalámbrica 802.11, o inalámbrica 3GPP) o en un servicio "Dial" (incluyendo PSTN telefónica y
RDSI) a los suscriptores. Los suscriptores son típicamente los clientes residenciales o de oficina pequeña / oficina en casa (SOHO).
Los clientes residenciales son generalmente depende enteramente de su proveedor de acceso a todos los servicios, mientras que
un SOHO compra algunos servicios del proveedor de acceso y puede proporcionar otros por sí mismo. Las redes que venden
servicios de tránsito a nadie más - SOHO, y redes empresariales residenciales - son generalmente arbitrados como "redes EDGE";
redes de tránsito son considerados como parte del "núcleo" de la Internet y las redes de acceso están entre los dos. Esta estructura
general se representa en la Figura 3. mientras que una compra SOHO algunos servicios del proveedor de acceso y puede
proporcionar otros por sí mismo. Las redes que venden servicios de tránsito a nadie más - SOHO, y redes empresariales
residenciales - son generalmente arbitrados como "redes EDGE"; redes de tránsito son considerados como parte del "núcleo" de la
Internet y las redes de acceso están entre los dos. Esta estructura general se representa en la Figura 3. mientras que una compra
SOHO algunos servicios del proveedor de acceso y puede proporcionar otros por sí mismo. Las redes que venden servicios de
tránsito a nadie más - SOHO, y redes empresariales residenciales - son generalmente arbitrados como "redes EDGE"; redes de
tránsito son considerados como parte del "núcleo" de la Internet y las redes de acceso están entre los dos. Esta estructura general
se representa en la Figura 3.
------ ------
/ \ / \
/-\ / \ / \
| SOHO | --- + Acceso | | Empresa |
\-/ | servicio | | red |
/-\ | proveedor | | |
| Inicio | --- + | ------ | |
\-/ \ + ---+ + ---+ /
\ // \\ /
------ | tránsito | ----- |
servicio | | proveedor | |
|
\ /
\ /
------
Figura 3: Modelo conceptual de las empresas de Internet

Un ejemplo específico se muestra en un traceroute de un hogar a una escuela cercana.

conectividad a Internet en la Figura 4 pasa a través
o la red doméstica,
O Cox Communications, una red de acceso utilizando la tecnología de módem por cable,
o Redes TransitRail, una mercancía servicio para la investigación y la educación

mirando (I + E),
o Corporación para la Educación Red de Iniciativas en California (CENIC), un

proveedor de tránsito para los contenidos educativos y el
o la Universidad de California en Santa Bárbara, que en este contexto podría ser visto como
una red de acceso de sus estudiantes y profesores o como una red empresarial.
<Stealth-10-32-244-218:>% traceroute www.ucsb.edu traceroute Fred a

web.ucsb.edu (128.111.24.41),
64 lúpulo max, 40 paquetes de bytes
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 ... 8
dc-lax-core1--lax-peer1-ge.cenic.net DC
-lax-agg1--lax-core1-ge.cenic.net ... 9 ... 10
dc-ucsb--dc-lax-dc2.cenic.net
r2--r1--1.commserv.ucsb.edu ... 11 ... 12
574-c--r2--2.commserv.ucsb.edu * * *
Figura 4: Traceroute de cliente residencial para la Educación

Institución
Otro ejemplo específico se pudo demostrar en un traceroute desde el hogar a través de una red
privada virtual (túnel VPN) de la casa, cruzando Cox Cable (una red de acceso) y Pacific Bell (una
red de tránsito), y que termina en Cisco Systems (una empresa red); un traceroute de la ruta no
muestra que a medida que es invisible dentro de la VPN y el contenido de la VPN son invisibles,
debido a la encriptación, a las redes en el camino. En cambio, el traceroute en la Figura 5 está
enteramente dentro de la red interna de Cisco.

<Stealth-10-32-244-218: ~> Fred% traceroute IRP-view13 traceroute a

irp-view13.cisco.com (171.70.120.60),
64 lúpulo max, 40 paquetes de bytes
1 fred-vpn (10.32.244.217) 2.560 ms 1.100 ms 1.198 ms
<Ruta de acceso a través de un túnel Cox y 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 ...
Figura 5: Traceroute a través de VPN
Nótese que en ambos casos, la red doméstica utiliza la dirección privada del espacio [ RFC1918 ]
Mientras que otras redes suelen utilizar espacio de direcciones públicas, y que las tres tecnologías de
middleware están en uso aquí. Estos son los usos de un cortafuegos, un traductor de direcciones de
red (NAT) y una red privada virtual (VPN).
Los cortafuegos se venden generalmente como y consideradas por muchos como una tecnología de
seguridad. Esto se basa en el hecho de que un servidor de seguridad impone una frontera entre dos
dominios administrativos. Por lo general, un servidor de seguridad se desplegará entre un residencial,
SOHO, o red de la empresa y su acceso o proveedor de tránsito. En su esencia, un firewall es un
diodo de datos, la imposición de una política sobre lo que pueden pasar entre sesiones de un dominio
protegido y el resto de Internet. políticas simples generalmente permiten sesiones que se originó a
partir de la red protegida, pero no desde el exterior; políticas más complejas pueden permitir sesiones
adicionales desde el exterior, tales como el correo electrónico a un servidor de correo o una sesión
web a un servidor web, y pueden prevenir ciertas aplicaciones de acceso global a pesar de que se
originan desde el interior.
Tenga en cuenta que la eficacia de los cortafuegos sigue siendo controvertido. Mientras que los administradores
de red a menudo insisten en el despliegue de servidores de seguridad, ya que imponen un límite, otros señalan
que su valor como solución de seguridad es discutible. Esto se debe a que la mayoría de los ataques provienen
de detrás del firewall. Además, los cortafuegos no protegen contra ataques a nivel de aplicación, tales como los
virus que transmiten en el correo electrónico. Por lo tanto, como solución de seguridad, los cortafuegos están
justificadas como una capa en la defensa en profundidad. Es decir, mientras un sistema final debe ser al final
responsable de su propia seguridad, un firewall puede inhibir o prevenir ciertos tipos de ataques, por ejemplo, el
consumo de tiempo de CPU en el servidor crítico.

Los documentos clave que describen la tecnología de servidor de seguridad y las cuestiones que plantea incluir:
o multidifusión IP y servidores de seguridad [ RFC2588 ]
o Evaluación comparativa de Terminología para la ejecución Firewall [ RFC2647 ]
o Comportamiento y los requisitos de Internet Firewalls [ RFC2979 ]
o Metodología de evaluación comparativa para la ejecución Firewall [ RFC3511 ]
O Mobile IPv6 y cortafuegos: Planteamiento del problema [ RFC4487 ]
o NAT y firewall transversal Cuestiones de Identidad anfitrión Protocolo de Comunicación

[ RFC5207 ]
La traducción de direcciones de red es una tecnología que fue desarrollada en respuesta a los comportamientos del
ISP en los mediados de los años 1990; cuando [ RFC1918 ] estaba

publicados, muchos ISP comenzaron a repartir los números individuales o pequeños de direcciones, y
las redes de borde se vieron obligados a traducir. Con el tiempo, esto se convirtió consideraba una
buena cosa, o al menos no es algo malo; se amplifica el espacio de direcciones públicas, y se vende
como si fuera un servidor de seguridad. Es, por supuesto, no lo es; mientras NAT dinámicas
tradicionales sólo se traducen entre tuplas dirección / puerto de sesión interna y externa durante la
duración detectada de la sesión, que el estado de sesión puede existir en la red mucho más tiempo de
lo que existe en el sistema final, y como resultado constituye un vector de ataque. El diseño, el valor y
las limitaciones de la traducción de direcciones de red se describen en:
o Red IP Address Translator Terminología y Consideraciones [

RFC2663 ]
o Red IP Tradicional traductor de direcciones [ RFC3022 ]
Las complicaciones o protocolo con el traductor de direcciones de red IP [

RFC3027 ]
o Red traductor de direcciones admiten Instrucciones de diseño de aplicaciones [

RFC3235 ]
o Consideraciones IAB Network Address Translation [ RFC3424 ]
o IPsec de red-Requisitos de compatibilidad traducción de direcciones [

RFC3715 ]
Requisitos de comportamiento o Direcciones de Red de unidifusión UDP [

RFC4787 ]

O Estado de Comunicación Peer-to-Peer través de traductores de direcciones de red [

RFC5128 ]
o Requisitos de multidifusión IP de un traductor de direcciones de red y una dirección de red

Puerto traductor [ RFC5135 ]
Redes privadas virtuales vienen en muchas formas; lo que tienen en común es que son generalmente
túnel a través de la red troncal de Internet, por lo que, como en la Figura 5, aparece la conectividad
estar totalmente dentro de la red de borde a pesar de que es, de hecho, a través de la red de un
proveedor de servicios. Los ejemplos incluyen IPsec en modo túnel túneles cifrados, iPIN-IP o túneles
GRE, y MPLS LSP [
RFC3031 ] [RFC3032].
5 . Consideraciones de Seguridad
La seguridad se tratan con cierto detalle en sección 2.2 y sección 3.1 .
6 . Expresiones de gratitud
Revisar comentarios fueron hechos por Adrian Farrel, Andrew Yourtchenko, Ashok Narayanan, Bernie
Volz, Chris Lonvick, Dan Romascanu, Dave McGrew, Dave Oran, David Harrington, David Su, Don
Sturek, Francis Cleveland, Hemant Singh, James Polk, Jari Arkko, John Meylor, Joseph Salowey, Julien
Abeille, Kerry Lynn, Lars Eggert, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman, Peter
Saint-Andre, Ralph Droms, Robert Sparks, Russ blanca, Sean Turner, Sheila Frankel, Stephen Farrell,
Tim Polk, Toerless Eckert, Tom Herbst, Vint Cerf, y Yoshihiro Ohba. Varios de los individuos sugirió un
texto, que era muy útil, ya que los autores no pretenden conocer la mitad que sus revisores
colectivamente hacen.
7 . referencias
7.1 . Referencias normativas
[RFC1122] Braden, R., "Requisitos para hosts de Internet Capas de

comunicación", STD 3, RFC 1122 ,
Octubre de 1989.
[RFC1123] Braden, R., "Requisitos para hosts de Internet Aplicación y

soporte", STD 3, RFC 1123 ,
Octubre de 1989.
[RFC1812] Baker, F., "Requisitos para IP versión 4 Routers",

RFC 1812 , Junio de 1995.
[RFC4294] Loughney, J., "Requisitos de nodos IPv6", RFC 4294 ,

Abril de 2006.

7.2 . Referencias informativas
[6LoWPAN-HC] Hui, J. y P. Thubert, "Formato de compresión para IPv6

Datagramas en redes de baja potencia y con pérdida
(6LoWPAN)", Work in Progress, febrero de 2011.
[ABFAB-ARCH] Howlett, J., Hartman, S., Tschofenig, H., y E.

Lear, "Aplicación de correspondencia a Federated Beyond Access Web
(ABFAB) Arquitectura", Work in Progress, marzo de 2011.
[AES-CCM-ECC] McGrew, D., Bailey, D., Campagna, M., y R. Dugal,

"AES-CCM ECC Cipher Suites para TLS", Work in Progress,
enero de 2011.
[COAP] Shelby, Z., Hartke, K., Bormann, C. y B. Frank, "Protocolo de

aplicación restringida (COAP)", Work in Progress, marzo de 2011.
[DIME-BASE] Fajardo, V., Ed., Arkko, J., Loughney, J. y G. Zorn, "Protocolo

Diámetro de la base", Work in Progress, enero de 2011.
[DNS-SD] Cheshire, S. y M. Krochmal, "DNS-base de descubrimiento de servicios",

Work in Progress, febrero de 2011.
[DTLS] Rescorla, E. y N. Modadugu, "datagramas de Transport Layer Security

versión 1.2", Work in Progress, marzo de 2011.
[DYMO] Chakeres, I. y C. Perkins, "Dynamic MANET Ondemand (DYMO) de

enrutamiento", Work in Progress, julio de 2010.
[IEC61850] Wikipedia, "el artículo de Wikipedia: IEC 61850", junio de

2011, < http://en.wikipedia.org/w/
index.php? title = IEC_61850 y oldid = 433437827 >.
[IEC62351-3] Comité Internacional de la Comisión Electrotécnica Técnica 57,

"Administración de energía y sistemas de información asociada INTERCAMBIO
DE DATOS Y COMUNICACIONES DE SEGURIDAD - Parte 3:. La red de
comunicación y perfiles de seguridad del sistema, incluyendo TCP / IP", mayo de
2007.
[IEEE802.1X] Instituto de Ingenieros Eléctricos y Electrónicos, "Norma IEEE

para local y redes de área metropolitana - Control de acceso de red
basada en el puerto", IEEE 802.1X estándar-2010, febrero de 2010.

[IP-SEC] Gont, F., "Evaluación de la Seguridad del protocolo de Internet

versión 4", Work in Progress, abril de 2011.
[IPv6-NODO-REQ] Jankiewicz, E., Loughney, J., y T. Narten, "IPv6

Requisitos de estación", Work in Progress, mayo de 2011.
[MULTICAST-DNS] Cheshire, S. y M. Krochmal, "DNS de multidifusión" , Trabajo
in Progress, de febrero de 2011.
[Modelo] SGIP, "red inteligente Comité de Arquitectura: Modelo conceptual Libro

Blanco http://collaborate.nist.gov/
twiki-sggrid / pub / Smartgrid /
SGIPConceptualModelDevelopmentSGAC /
Smart_Grid_Conceptual_Model_20100420.doc".
[OAUTHv2] Hammer-Lahav, E., Recordon, D. y D. Hardt, "El OAuth 2.0 Protocolo de

autorización", Work in Progress, mayo de 2011.
[SOSEGADO] Fielding, "estilos arquitectónicos y el diseño de arquitecturas de

software basados en la red", 2000.
[RFC0768] Postel, J., "Protocolo de Datagrama de Usuario", STD 6,

RFC 768 , Agosto de 1980.
[RFC0791] Postel, J., "Protocolo de Internet", STD 5, RFC 791 ,

De septiembre de 1981.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,

RFC 792 , Septiembre de 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,

[RFC0826] Plummer, D., "Protocolo de Resolución de Dirección de Ethernet: o

convertir direcciones de protocolo de red para 48.bit dirección Ethernet para la
transmisión en hardware Ethernet", STD 37,
RFC 826 , Noviembre de 1982.
[RFC0894] Hornig, C., "Norma para la transmisión de datagramas IP sobre

redes Ethernet", STD 41, RFC 894 ,
De abril de 1 984.
[RFC1006] Rose, M. y D. Cass, "servicios de transporte ISO en la parte superior de la

TCP: Version 3", STD 35, RFC 1006 , Mayo de 1987.
[RFC1034] Mockapetris, P., "Nombres de dominio - Conceptos y Servicios",

STD 13, RFC 1034 , Noviembre de 1,987.

[RFC1035] Mockapetris, P., "Los nombres de dominio - y aplicación Especificación",

STD 13, RFC 1035 , Noviembre de 1,987.
[RFC1058] Hedrick, C., "Protocolo de información de enrutamiento",

[RFC1112] Deering, S., "Anfitrión Extensiones para la multidifusión IP", STD 5,

[RFC1195] Callon, R., "El uso de OSI IS-IS para el encaminamiento en TCP / IP y
ambientes duales", RFC 1195 , Diciembre de 1990.
[RFC1332] McGregor, G., "El PPP Protocolo de Internet Control Protocol

(IPCP)", RFC 1332 , Mayo de 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,

RFC 1661 , Julio de 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,

G. y E. Lear, "Asignación de direcciones para Internets privadas",
BCP 5 , RFC 1918 , Febrero de 1996.
[RFC1964] Linn, J., "La versión Kerberos Mecanismo de 5 GSS-API",

[RFC2080] Malkin, G. y R. Minnear, "RIPng para IPv6",

RFC 2080 , Enero de 1997.
[RFC2126] Pouffary, Y. y A. Young, "Servicio de Transporte ISO en la parte superior de TCP

(ITOT)", RFC 2126 , Marzo de 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",

RFC 2131 , Marzo de 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., y J. Bound, "Actualizaciones

dinámicas en el Sistema de Nombres de Dominio (DNS UPDATE)",
RFC 2136 , Abril de 1997.
[RFC2328] Moy, J., "OSPF Versión 2", STD 54, RFC 2328 ,
Abril de 1998.
[RFC2357] Mankin, A., Romanov, A., Bradner, S., y V. Paxson, "Criterios IETF para la
evaluación fiable de Transporte de multidifusión y protocolos de aplicación",
RFC 2357 ,
Junio de 1998.
[RFC2453] Malkin, G., "RIP Versión 2", STD 56, RFC 2453 ,
Noviembre de 1998.

[RFC2460] Deering, S. y R. Hinden, "Protocolo de Internet versión 6 (IPv6)

Specification", RFC 2460 ,
Diciembre de 1998.
[RFC2464] Crawford, M., "La transmisión de paquetes IPv6 sobre redes

Ethernet", RFC 2464 , Diciembre de 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., y D. Negro, "Definición del
campo de servicios diferenciados (DS Field) en los encabezados de
IPv4 e IPv6", RFC 2474 ,
Diciembre de 1998.
[RFC2475] Blake, S., Negro, D., Carlson, M., Davies, E., Wang,
Z., y W. Weiss, "Una Arquitectura de Servicios
diferenciados", RFC 2475 , Diciembre de 1998.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., y
R. Wheeler, "un método para transmitir PPP sobre Ethernet
(PPPoE)", RFC 2516 ,
Febrero de 1999.
[RFC2545] Marques, P. y F. Dupont, "El uso de BGP-4 Multiprotocol

Extensions para IPv6 Inter-Domain Routing",
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S. y C. Adams,

"Infraestructura de Clave Pública Internet X.509 Online Certificate Status
Protocol OCSP",
[RFC2588] Finlayson, R., "multidifusión IP y servidores de seguridad",
RFC 2588 , Mayo de 1999.
[RFC2608] Guttman, E., Perkins, C., Veizades, J. y M. Day, "Service Location

Protocol, versión 2", RFC 2608 ,
Junio de 1999.
[RFC2615] Malis, A. y W. Simpson, "PPP sobre SONET / SDH",

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. y T. Berners-Lee, "Protocolo de Transferencia de
Hipertexto - HTTP / 1.1", RFC 2616 ,
Junio de 1999.
[RFC2647] Newman, D., "Evaluación comparativa de Terminología para la ejecución

Firewall", RFC 2647 , Agosto de 1999.

[RFC2663] Srisuresh, P. y M. Holdrege, "Red IP Address Translator (NAT)

Terminología y Consideraciones",
[RFC2710] Deering, S., Fenner, W., y B. Haberman, "Multicast Listener Discovery

(MLD) para IPv6", RFC 2710 ,
Octubre de 1999.
[RFC2743] Linn, J., "Seguridad de Servicios de Aplicación Programa

Interfaz versión genérica 2, Update 1", RFC 2743 ,
Enero de 2000.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., y P. Traina, "Generic
Routing Encapsulation (GRE)",
[RFC2865] Rigney, C., Willens, S., Rubens, A., y W. Simpson, "Dial de autenticación
remota de usuario Service (RADIUS)",
[RFC2979] Freed, N., "Comportamiento y los requisitos de Internet

Firewalls", RFC 2979 , Octubre de 2000.
[RFC2993] Hain, T., "Implicaciones arquitectónicos de NAT",

[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Actualización

dinámica", RFC 3007 , Noviembre de 2000.
[RFC3022] Srisuresh, P. y K. Egevang, "tradicional de direcciones de red

IP Traductor (NAT Tradicional)",
[RFC3027] Holdrege, M. y P. Srisuresh, "Complicaciones protocolo

con el traductor de direcciones de red IP",
[RFC3031] Rosen, E., Viswanathan, A., y R. Callon, "conmutación por

etiquetas multiprotocolo Arquitectura",
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li,
T., y A. Conta, "MPLS Label pila de codificación",
[RFC3168] Ramakrishnan, K., Floyd, S., y D. Negro, "La adición de

notificación explícita de congestión (ECN) al IP",

[RFC3235] Senie, D., "de direcciones de red (NAT del traductor) que admite
Directrices de diseño de la aplicación", RFC 3235 ,
Enero de 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,

Peterson, J., Sparks, R., Handley, M., y E. Schooler, "SIP: Protocolo de
Iniciación de Sesión",
[RFC3265] Roach, A., "Protocolo de Iniciación de Sesión (SIP) de notificación de

eventos específico", RFC 3265 , Junio de 2002.
[RFC3275] Eastlake, D., Reagle, J., y D. Solo, "(Extensible Markup Language) la

firma XML Sintaxis y Procesamiento",
[RFC3315] Droms, R., Bound, J., Volz, B., limón, T., Perkins,
C. y M. Carney, "Dynamic Host Configuration Protocol para IPv6
(DHCPv6)", RFC 3315 , Julio de 2003.
[RFC3376] Caín, B., Deering, S., Kouvelas, I., Fenner, B., y

A. Thyagarajan, "Internet Group Management Protocol, versión 3",
RFC 3376 , Octubre de 2002.
[RFC3411] Harrington, D., Presuhn, R. y B. Wijnen, "Una Arquitectura para la

Descripción de Simple Network Management Protocol (SNMP Marcos) Gestión",
STD 62,
RFC 3411 , Diciembre de 2002.
[RFC3412] Caso, J., Harrington, D., Presuhn, R. y B. Wijnen, "procesamiento de

mensajes y el envío para el Simple Network Management Protocol (SNMP)",
STD 62,
[RFC3413] Levi, D., Meyer, P. y B. Stewart, "Simple Network Management Protocol

(SNMP) Aplicaciones", STD 62,
[RFC3414] Blumenthal, U. y B. Wijnen, "basada en el usuario Modelo de Seguridad

(USM) para la versión 3 del protocolo de gestión de red simple (SNMPv3)",
STD 62, RFC 3414 ,
Diciembre de 2002.
[RFC3415] Wijnen, B., Presuhn, R. y K. McCloghrie, "Viewbased acceso Modelo

de Control (VACM) para el Simple Network Management Protocol (SNMP)",
STD 62,

[RFC3416] Presuhn, R., "La versión 2 del protocolo de operaciones para el

Simple Network Management Protocol (SNMP)", STD 62,
[RFC3417] Presuhn, R., "Asignaciones de Transporte para el Simple Network

Management Protocol (SNMP)", STD 62,
[RFC3418] Presuhn, R., "Management Information Base (MIB) para el Simple Network
Management Protocol (SNMP)", STD 62,
[RFC3424] Daigle, L. y IAB, "IAB Consideraciones para la fijación

unilateral Auto-Dirección (UNSAF) a través de la traducción de
direcciones de red", RFC 3424 ,
Noviembre de 2002.
[RFC3436] Jungmaier, A., Rescorla, E. y M. Tuexen, "Transport Layer

Security sobre secuencia del protocolo de control de transmisión",
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., y J.
Crowcroft, "El uso de Forward Error Correction (FEC) en Multicast
fiable",
[RFC3511] Hickman, B., Newman, D., Tadjudin, S. y T. Martin, "Metodología

de evaluación comparativa para la ejecución Firewall",
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. y V. Jacobson, "RTP: Un

Protocolo de transporte para aplicaciones en tiempo real", STD 64,
[RFC3552] Rescorla, E. y B. Korver, "Directrices para elaborar RFC texto en

Consideraciones de Seguridad", BCP 72 ,
[RFC3561] Perkins, C., Belding-Royer, E., y S. Das, "Ad hoc On-Demand Vector
de Distancia (AODV) Routing", RFC 3561 ,
Julio de 2003.
[RFC3569] Bhattacharyya, S., "Una visión general de Origen Específicas Multicast

(SSM)", RFC 3569 , Julio de 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. y J. Arkko,

"protocolo Diameter Base", RFC 3588 ,
Septiembre de 2003.

[RFC3590] Haberman, B., "Selección de la fuente de direcciones para el

Protocolo Multicast Listener Discovery (MLD)",
[RFC3626] Clausen, T. y P. Jacquet, "Optimización de estado de enlace

(OLSR)", RFC 3626 , Octubre de 2003.
[RFC3629] Yergeau, F., "UTF-8, un formato de transformación de la norma ISO 10646",

STD 63, RFC 3629 , Noviembre de 2003.
[RFC3715] Aboba, B. y W. Dixon, "IPsec-Network Address Translation (NAT)

Requisitos de compatibilidad",
[RFC3810] Vida, R. y L. Costa, "Multicast Listener Discovery Version 2 (MLDv2)

para IPv6", RFC 3810 , Junio de 2004.
[RFC3828] Larzon, LA., Degermark, M., Rosa, S., Jonsson, LE., Y G.

Fairhurst, "El Protocolo de Datagrama de peso ligero de usuario
(UDP-Lite)", RFC 3828 , Julio de 2004.
[RFC3853] Peterson, J., "S / MIME Advanced Encryption Standard (AES) Requisito
para el Protocolo de Iniciación de Sesión (SIP)",
[RFC3923] Saint-Andre, P., "Firma de extremo a extremo y el cifrado del objeto

para el Protocolo de Mensajería y Presencia extensible (XMPP)",
RFC 3923 En octubre de 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., y P. Nikander, "Secure Vecino
Descubrimiento (SEND)", RFC 3971 ,
Marzo de 2005.
[RFC3973] Adams, A., Nicholas, J. y W. Siadak, "Protocolo Multicast

Independiente - Modo Denso (PIM-DM): Especificación del protocolo
(Revisada)", RFC 3973 ,
Enero de 2005.
[RFC4017] Stanley, "Requisitos de protocolo de autenticación extensible (EAP)

Método para LANs inalámbricas" D., Walker, J., y B. Aboba,,
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., y

S. Rose, "Seguridad DNS Introducción y Requisitos",


S. Rose, "Registros de Recursos para las extensiones de seguridad del DNS",

S. Rose, "Protocolo de Modificación de la Seguridad DNS
Extensions", RFC 4035 , Marzo de 2005.
[RFC4108] Housley, R., "Uso de sintaxis de mensajes criptográficos (CMS) para

proteger los paquetes de firmware", RFC 4108 ,
Agosto de 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., y K. Raeburn, "El Servicio de
autenticación de red Kerberos (V5)",
[RFC4121] Zhu, L., Jaganathan, K. y S. Hartman, "El Servicio de Interfaz de

Kerberos versión 5 de seguridad genérico Aplicación del Programa
(GSS-API) Mecanismo: Versión 2",
[RFC4210] Adams, C., Farrell, S., Kause, T. y T. Mononen, "Internet X.509 Public
Key Infrastructure Protocolo de Gestión de certificados (CMP)",
RFC 4210 ,
Septiembre de 2005.
[RFC4213] Nordmark, E. y R. Gilligan, "Mecanismos de Transición básicos

para IPv6 Hosts y Routers", RFC 4213 ,
Octubre de 2005.
[RFC4253] Ylonen, T. y C. Lonvick, "El Secure Shell (SSH) Protocolo de capa de

transporte", RFC 4253 , Enero de 2006.
[RFC4271] Rekhter, Y., Li, T., y S. liebres, "una frontera de pasarela de protocolo 4
(BGP-4)", RFC 4271 , Enero de 2006.
[RFC4291] Hinden, R. y S. Deering, "IP versión 6 frente a la arquitectura",

RFC 4291 , Febrero de 2006.
[RFC4301] Kent, S. y K. Seo, "Arquitectura de Seguridad para el Protocolo de

Internet", RFC 4301 , Diciembre de 2005.
[RFC4302] Kent, S., "Authentication Header IP", RFC 4302 ,

Diciembre de 2005.
[RFC4303] Kent, S., "IP Carga de Seguridad Encapsulada (ESP)",


[RFC4307] Schiller, J., "Algoritmos criptográficos para uso en el intercambio de

claves de Internet versión 2 (IKEv2)",
[RFC4320] Sparks, R., "Acciones para afrontar identificado problemas con (SIP)
NonINVITE Transacción del Protocolo de Iniciación de Sesión",
[RFC4340] Kohler, E., Handley, M., y S. Floyd, "Protocolo de Control de

datagramas de congestión (DCCP)", RFC 4340 ,
Marzo de 2006.
[RFC4347] Rescorla, E. y N. Modadugu, "datagramas de Transport Layer Security",

[RFC4364] Rosen, E. e Y. Rekhter, "MPLS IP Redes BGP / privadas virtuales

(VPN)", RFC 4364 , Febrero de 2006.
[RFC4410] Pullen, M., Zhao, F., y D. Cohen, "Protocolo de Multidifusión

Fiable selectivamente (SRMP)", RFC 4410 ,
Febrero de 2006.
[RFC4422] Melnikov, A. y K. Zeilenga, "Capa de autenticación y seguridad (SASL)",

[RFC4443] Conta, A., Deering, S., y M. Gupta, "Protocolo de mensajes de

control de Internet (ICMPv6) para el Protocolo de Internet versión 6
(IPv6) Specification", RFC 4443 ,
Marzo de 2006.
[RFC4487] Le, F., Faccin, S., Patil, B. y H. Tschofenig, "Mobile IPv6 y

cortafuegos: Planteamiento del problema",
RFC 4487 , Mayo de 2006.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., y B. Moeller,
"criptografía de curva elíptica (ECC) Cipher Suites para la Seguridad de capa
de transporte (TLS)",
RFC 4492 , Mayo de 2006.
[RFC4556] Zhu, L. y B. Tung, "criptografía de clave pública para la autenticación

inicial en Kerberos (PKINIT)",
[RFC4566] Handley, M., Jacobson, V., y C. Perkins, "SDP: Session Description

Protocol", RFC 4566 , Julio de 2006.

[RFC4594] Babiarz, J., Chan, K., y F. Baker, "Directrices de configuración para

clases de servicio DiffServ", RFC 4594 ,
Agosto de 2006.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., y I. Kouvelas, "Protocolo

Independiente Multicast - Sparse Mode (PIM-SM): Especificación de
Protocolo (revisado)",
[RFC4604] Holbrook, H., Caín, B. y B. Haberman, "Uso de Internet Group

Management Protocol Version 3 (IGMPv3) y Multicast Listener Discovery
Protocol Version 2 (MLDv2) de Origen Específicas Multicast",
[RFC4607] Holbrook, H. y B. Caín, "Multicast Origen Específicas por la PI",

[RFC4608] Meyer, D., Rockell, R. y G. Shepherd, "SourceSpecific Multicast

independiente de protocolo de 232/8",
BCP 120 , RFC 4608 , Agosto de 2006.
[RFC4614] Duke, M., Braden, R., Eddy, W. y E. Blanton, "Plan de trabajo para
Transmission Control Protocol (TCP Documentos) Especificación",
[RFC4741] Enns, R., "Protocolo de configuración NETCONF",

[RFC4742] Wasserman, M. y T. Goddard, "Uso del Protocolo NETCONF de

configuración a través de Secure Shell (SSH)",
[RFC4743] Goddard, T., "Uso de NETCONF sobre el Protocolo simple de acceso a

objetos (SOAP)", RFC 4743 , Diciembre de 2006.
[RFC4744] Lear, E. y K. Crozier, "Uso del Protocolo NETCONF sobre el protocolo de

intercambio Extensible Blocks (BEEP)",
[RFC4760] Bates, T., Chandra, R., Katz, D., y Y. Rekhter, "Multiprotocol

Extensions para BGP-4", RFC 4760 ,
Enero de 2007.
[RFC4787] Audet, F. y C. Jennings, "Network Address Translation (NAT)

Requisitos de comportamiento para Unicast UDP",
BCP 127 , RFC 4787 , Enero de 2007.

[RFC4835] Manral, V., "Algoritmo criptográfico Requisitos de Ejecución para la

carga de seguridad encapsuladora (ESP) y Authentication Header (AH)",
RFC 4835 ,
Abril de 2007.
[RFC4854] Saint-Andre, P., "un recurso de nombre uniforme (URN) de espacio de

nombres para las extensiones a la mensajería extensible and Presence Protocol
(XMPP)", RFC 4854 ,
Abril de 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W. y H. Soliman, "Vecino

Descubrimiento de IP versión 6 (IPv6)",
[RFC4862] Thomson, S., Narten, T., y T. Jinmei, "IPv6 Autoconfiguración

dirección sin estado", RFC 4862 ,
Septiembre de 2007.
[RFC4916] Elwell, J., "Identidad conectados en el Protocolo de Iniciación

de Sesión (SIP)", RFC 4916 , Junio de 2007.
[RFC4919] Kushalnagar, N., Montenegro, G. y C. Schumacher, "IPv6 sobre Low-Power

Wireless Personal Area Networks (6LoWPANs): Descripción general, Supuestos,
planteamiento del problema, y Metas",
[RFC4941] Narten, T., Draves, R., y S. Krishnan, "Extensiones de privacidad para

la autoconfiguración de direcciones sin estado en IPv6",
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., y D. Culler, "Transmisión

de paquetes IPv6 a través de IEEE
802.15.4 Redes", RFC 4944 , Septiembre de 2007.
[RFC4960] Stewart, R., "Protocolo de Control de Transmisión Stream",

[RFC4987] Eddy, W., "ataques por inundación TCP SYN y mitigaciones comunes",
[RFC5023] Gregorio, J. y B. de Hora, "El protocolo de publicación Atom",

[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., y

M. Kozuka, "Protocolo de control de transmisión de flujo (SCTP)
Reconfiguración de direcciones dinámicas", RFC 5061 ,
Septiembre de 2007.

[RFC5072] Varada, S., Ed., Haskins, D., y E. Allen, "IP versión 6 sobre
PPP", RFC 5072 , Septiembre de 2007.
[RFC5122] Saint-Andre, P., "internacionalizados de recursos Identificadores

(IRI) y los identificadores uniformes de recursos (URI) para el Protocolo
extensible de mensajería y presencia (XMPP)",
[RFC5128] Srisuresh, P., Ford, B. y D. Kegel, "Estado de Peer-to-Peer

(P2P) La comunicación a través de direcciones de red (NAT
Traductores)", RFC 5128 , Marzo de 2008.
[RFC5135] Ala, D. y T. Eckert, "Requisitos de multidifusión IP de un traductor de

direcciones de red (NAT) y un puerto traductor de direcciones de red
(NAPT)", BCP 135 , RFC 5135 ,
Febrero de 2008.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., y A. Yegin,
"Protocolo de llevar autenticación para el acceso de red (PANA)",
RFC 5191 , Mayo de 2008.
[RFC5207] Stiemerling, M., Quittek, J. y L. Eggert, "NAT y Firewall Temas

Transversales del Host Protocolo de Identidad (HIP) Comunicación",
[RFC5216] Simon, D., Aboba, B. y R. Hurst, "El EAP-TLS Protocolo de

autenticación", RFC 5216 , Marzo de 2008.
[RFC5238] Phelan, T., "datagramas de Transport Layer Security (DTLS) sobre el

Protocolo de Datagrama de control de la congestión (DCCP)",
RFC 5238 , Mayo de 2008.
[RFC5246] Dierks, T. y E. Rescorla, "La Transport Layer Security (TLS)

Protocol Version 1.2", RFC 5246 ,
Agosto de 2008.
[RFC5272] Schaad, J. y M. Myers, "Gestión de certificados a través de CMS

(CMC)", RFC 5272 , Junio de 2008.
[RFC5277] Chisholm, S. y H. Treviño, "NETCONF notificaciones de eventos",

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., housley, R. y W.
Polk, "Internet X.509 infraestructura de clave pública y la lista de certificados
revocados (CRL) Perfil",
RFC 5280 , Mayo de 2008.

[RFC5289] Rescorla, E., "TLS cifrado de curva elíptica Suites con SHA-256/384 y
AES Galois modo contador (GCM)",
[RFC5308] Hopps, C., "Enrutamiento IPv6 con IS-IS", RFC 5308 ,

Octubre de 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., y A. Lindem, "OSPF para IPv6",
[RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A. y B. Campen, "Hacer

frente a una vulnerabilidad de amplificación en la sesión de protocolo de
inicio (SIP) que bifurca proxies",
[RFC5405] Eggert, L. y G. Fairhurst, "Unicast UDP Directrices de uso para los

diseñadores de aplicaciones", BCP 145 ,
[RFC5430] Salter, M., Rescorla, E. y R. Housley, "Suite B Perfil de Transport

Layer Security (TLS)",
[RFC5433] Clancy, T. y H. Tschofenig, "Protocolo de Autenticación Extensible

- Generalizado Pre-Shared Key (EAP-GPSK) Método",
[RFC5437] Saint-Andre, P. y A. Melnikov, "Mecanismo Tamiz Notificación:

Extensible Messaging and Presence Protocol (XMPP)",
[RFC5539] Badra, M., "NETCONF más de Transporte de Seguridad (TLS)",

RFC 5539 , Mayo de 2009.
[RFC5545] Desruisseaux, B., "Internet Calendarios y especificación del

objeto Programación Core (iCalendar)",
[RFC5546] Daboo, C., "Protocolo de interoperabilidad independiente del

transporte de iCalendar (iTIP)", RFC 5546 ,
Diciembre de 2009.
[RFC5548] Dohler, M., Watteyne, T., Invierno, T. y D. Barthel, "Requisitos

para las Rutas del Urban baja potencia y con pérdidas Redes",
RFC 5548 , Mayo de 2009.
[RFC5569] Despres, R., "IPv6 Despliegue Rápido de Infraestructuras de

IPv4 (6RD)", RFC 5569 , Enero de 2010.

[RFC5621] Camarillo, G., "Cuerpo del mensaje de manipulación en el Protocolo de Iniciación de

Sesión (SIP)", RFC 5621 ,
Septiembre de 2009.
[RFC5626] Jennings, C., Mahy, R., y F. Audet, "Gestión de conexiones iniciada

por el cliente en el Protocolo de Iniciación de Sesión (SIP)",
[RFC5652] Housley, R., "sintaxis de mensajes criptográficos (CMS)", STD 70,

[RFC5673] Pister, K., Thubert, P., Dwars, S. y T. Phinney, "Requisitos de

contorneado industrial en baja potencia y con pérdidas Redes",
[RFC5681] Allman, M., Paxson, V., y E. Blanton, "Control TCP

Congestión", RFC 5681 , Septiembre de 2009.
[RFC5717] Lengyel, B. y M. Bjorklund, "Bloqueo parcial llamada a procedimiento

remoto (RPC) para NETCONF", RFC 5717 ,
Diciembre de 2009.
[RFC5740] Adamson, B., Bormann, C., Handley, M., y J. Macker,

"NACK-Oriented protocolo fiable Multicast (NORM) de transporte",
[RFC5751] Ramsdell, B. y S. Turner, "Secure Multipurpose Internet Mail

Extensions / (S / MIME) Versión 3.2 especificación del mensaje",
[RFC5785] Nottingham, M. y E. Hammer-Lahav, "Definición de WellKnown

identificadores uniformes de recursos (URIs)",
[RFC5826] Brandt, A., Burón, J. y G. Porcu, "Requisitos de automatización del

hogar de encaminamiento en baja potencia y con pérdidas Redes",
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., y

R. Aggarwal, "Apoyo a Familias de direcciones en OSPFv3",
[RFC5849] Hammer-Lahav, E., "El protocolo OAuth 1.0",


[RFC5867] Martocci, J., De Mil, P., Riou, N. y W. Vermeylen, "Automatización de

Edificios de enrutamiento Requisitos de baja potencia y con pérdidas Redes",
RFC 5867 ,
Junio de 2010.
[RFC5905] Mills, D., Martin, J., Burbank, J. y W. Kasch, "Tiempo de Red

versión 4 del protocolo: Protocolo y Algoritmos Specification",
[RFC5932] Kato, A., Kanda, M., y S. Kanno, "Camellia Cipher Suites para TLS",
[RFC5958] Turner, S., "Paquetes de clave asimétrica", RFC 5958 ,

Agosto de 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., y P. Eronen, "Internet Key
Cambio Protocol Version 2 (IKEv2)",
[RFC5998] Eronen, P., Tschofenig, H., y Y. Sheffer, "una extensión para

EAP-sólo la autenticación en IKEv2",
[RFC6031] Turner, S. y R. Housley, "sintaxis de mensajes criptográficos (CMS)

simétrica paquete de claves de tipo de contenido",
[RFC6047] Melnikov, A., "Protocolo de Interoperabilidad de

Mensaje-Based iCalendar (iMIP)", RFC 6047 ,
Diciembre de 2010.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., y X. Li, "IPv6
Direccionamiento de IPv4 / IPv6 Translators",
[RFC6090] McGrew, D., Igoe, K., y M. Salter, "fundamental criptografía de curva

elíptica algoritmos", RFC 6090 ,
Febrero de 2011.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP):

Core", RFC 6120 , Marzo de 2011.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP):

Mensajería Instantánea y Presencia",
[RFC6144] Baker, F., Li, X., Bao, C., y K. Yin, "Marco para IPv4 / IPv6
Translation", RFC RFC6144 , Abril de 2011.

[RFC6145] Li, X., Bao, C., y F. Baker, "Traducción IP / ICMP

Algoritmo", RFC 6145 , Abril de 2011.
[RFC6146] Bagnulo, M., Matthews, P. y I. Beijnum, "Stateful NAT64: Dirección de

red y el protocolo IPv6 traducción del clientes a servidores IPv4",
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P. y I. Beijnum, "DNS64:

Extensiones de DNS para direcciones de red de los clientes IPv6 a IPv4
Servidores",
[RFC6180] Arkko, J. y F. Baker, "Directrices para el uso Mecanismos de

Transición IPv6 durante Despliegue de IPv6",
RFC 6180 , Mayo de 2011.
[RPL] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey,
R., Levis, P., Pister, K., Struik,
R., y J. Vasseur, "RPL: Protocolo de enrutamiento de IPv6 para la energía
baja y con pérdidas Redes", Work in Progress, marzo de 2011.
CableLabs ", DOCSIS 3.0 Protocolos de capa [MULPIv3.0 SP-] MAC y superiores
Especificación de interfaz, CM-SP-MULPIv3.0-I10090529" , mayo
de 2009.
[Red inteligente] Wikipedia, "el artículo de Wikipedia: red inteligente",

Febrero de 2011, < http://en.wikipedia.org/w/
index.php? title = Smart_grid y oldid = 415838933 >.
[TCP-SEC] Gont, F., "Evaluación de la Seguridad del Protocolo de Control de

Transmisión (TCP)", Work in Progress, enero de 2011.
[R1822] Bolt Beranek y Newman Inc., "Procesador de interfaz de mensajes -

Especificaciones para la interconexión de un host y un IMP, Informe No.
1822", Enero 1976.
[Xcal] Daboo, C, Douglass, M. y S. Lees, "xcal: El formato XML para iCalendar",

Work in Progress, abril de 2011.

Apéndice A . Ejemplo: Infraestructura de Medición Avanzada
En este apéndice se ofrece un ejemplo práctico del uso del conjunto de protocolos de
Internet en una red como la infraestructura de medición avanzada de la red inteligente (IAM).
Hay varios modelos posibles.
La Figura 6 muestra la estructura de la AMI ya que llega hacia un conjunto de residencias. En esta
estructura, tenemos la casa en sí y su red de área Inicio (HAN), la Red de Vecindario (NAN) que la
utilidad utiliza para acceder al metro en la casa, y la red de acceso utilidad que conecta un conjunto de
NAN a la propia utilidad. A los efectos de esta discusión, supongamos que la NAN contiene una
aplicación distribuida en un conjunto de colectores, que por supuesto es sólo una forma en que la
aplicación podría ser implementado.
- - UN
termostatos, electrodomésticos, etc |
------ + ---------------------------------- |
|
| "HAN" | <--- Energy Services Interface (ESI) | + --- + --- + |
| metros | Meter es generalmente un ALG entre el IAM y la HAN | + --- + --- + V
\
--- \
UN \ | /
| \|/
| "NAN" + - + - + - + --- + probable un router, pero pude |
| Colector | ser una aplicación de V-extremo delantero
+ ----+ -----+ puerta de entrada para utilidad
--- \
UN \ | /
| \|/
| "AMI" + --+ -+ -+ --+
| | IAM |
| | cabecera | V
+ ---------+
---
Figura 6: La HAN, NAN y utilidad en la medición avanzada

Infraestructura
Hay varias preguntas que tienen que ser respondidas en la descripción de esta imagen, que
posibles respuestas dadas rinden diversos modelos posibles. Ellos incluyen al menos:
o ¿Cómo funciona respuesta a la demanda? Ya sea:

* La utilidad presenta señales de precios para el hogar,
* La utilidad presenta señales de precios a los dispositivos individuales (por ejemplo, un

enchufable del vehículo eléctrico),
* La utilidad ajusta configuración de aparatos individuales dentro de la casa.
o ¿Cómo los medidores de acceso utilidad en el hogar?
* El IAM cabecera gestiona las interfaces con los metros, la recogida de datos de
medición y transmitirlo a las aplicaciones apropiadas por el bus de la empresa, o
* soporte de aplicaciones distribuidas ( "colectores") pueden acceder y resumir la

información; este dispositivo podría ser gestionado por la empresa o por un servicio entre
la empresa y sus clientes.
En la aplicación, estos modelos son idealizada; la realidad puede incluir algunos aspectos de
cada modelo en los casos especificados.
Los ejemplos incluyen:
1. Apéndice A.2 presume que la HAN, la NAN, y la red de la utilidad son dominios
administrativos separados y hablan una aplicación a través de esos dominios.
2. Apéndice A.3 repite el primer ejemplo, pero suponiendo que la

utilidad accede directamente a aparatos dentro de la HAN desde el colector.
3. Apéndice A.4 repite el primer ejemplo, pero suponiendo que la

colector reenvía directamente tráfico como un router, además de las tareas de aplicaciones distribuidas.
Tenga en cuenta que este caso implica numerosos problemas de privacidad y seguridad, y como tal se
considera un modelo de implementación menos probable.
A.1 . Cómo estructurar una Red
Una consideración clave en el Internet ha sido el desarrollo de nuevas tecnologías de enlace con el
tiempo. La ARPANET originalmente utiliza una capa de enlace de propiedad BBN llamado BBN 1822
[ r1822 ]. A finales de la década de 1970,
la ARPANET cambió a X.25 como una interfaz a la red 1822. Con el despliegue de las
tecnologías de la serie IEEE 802 en la década de 1980, se desplegó IP en Ethernet (IEEE
802.3), Token Ring (IEEE
802.5) y WiFi (IEEE 802.11), así como Arcnet, líneas serie de diversos tipos, Frame Relay, y
ATM. Una cuestión clave en esta evolución fue que las aplicaciones desarrolladas para
funcionar en las API de uso de Internet

relacionado con el IPS, y como resultado requieren poco o ningún cambio de continuar operando en
una nueva arquitectura de capa de enlace o una mezcla de ellos.
La red inteligente es probable que veamos una evolución similar en el tiempo. Considere la red de
área Inicio (HAN) como una red pequeña fácilmente comprensible. En esta coyuntura, las
tecnologías propuestas para las redes residenciales incluyen IEEE P1901, varias versiones de
IEEE
802.15.4, e IEEE 802.11. Es razonable esperar que otras tecnologías que se desarrollarán en
el futuro. A medida que la ZigBee Alliance ha aprendido (y como resultó incorporado el IPS en
Smart Energy Perfil 2.0), hay un valor significativo en el suministro de una dirección virtual que
está asignado a interfaces o nodos conectados a cada una de esas tecnologías.

Utilidad NAN / /
+ ----+ -----+ + --+ + --+ + --+

| metros | | D1 | | D2 | | D3 |
+ -----+ ----+ + + -+ + + -+ + + -+
| | | |
- - - - + - + - - - - - - - + - - - - + - - - - + - - - - IEEE 802.15.4
|
+ --+ ---+
| Router + ------ / ------ banda ancha residencial
+ --+ ---+
|
- - - - + - - - - - - - - - + - - - - + - - - - + - - - - IEEE P1901
| | |
+ + -+ + + -+ + + -+
| D4 | | D5 | | D6 |
+ --+ + --+ + --+
UN termostatos, electrodomésticos, etc |
------ + ---------------- + ----------------- | "HAN" |
|
| + --- + --- + + ---+ ---+
| | Router | | metros |
| | O el EMS | | |
V + --- + --- + + ---+ ---+
--- | --- \
| ^ \ | /
| | "NAN" \|/
---+ --- | + --+ -+ -+ ---+
/ \ | | "Polo Top" |
| internet | v + ----+ -----+
\ / ---
-------
Figura 7: Dos puntos de vista de una red doméstica Área
Hay dos modelos de comunicación posibles dentro del Han, ambos de los cuales son
susceptibles de ser útiles. Los dispositivos pueden comunicarse directamente entre sí, o pueden
ser gestionados por algún controlador central. Un ejemplo de comunicación directa podría ser un
interruptor de luz que manda directamente una lámpara para encender o apagar. Un ejemplo de
comunicaciones indirectas podría ser una aplicación de control en un cliente o un edificio que
acepte la telemetría de un termostato, se aplica alguna forma de política, y controla los sistemas
de calefacción y aire acondicionado. Además, hay aparatos de alta gama en el mercado hoy en
día que utilizan banda ancha residencial para comunicarse con sus fabricantes, y, obviamente, el
medidor tiene que comunicarse con la utilidad.

La figura 7 muestra dos redes simples, una de las cuales utiliza 802.15.4 IEEE y IEEE 1901
dominios, y uno de los cuales utiliza una LAN arbitraria dentro de la casa, lo que podría ser IEEE
802.3 / Ethernet, IEEE 802.15.4, IEEE
1901, IEEE 802.11, o cualquier otra cosa que tenía sentido en su contexto. Ambos muestran la
conectividad entre ellos como un router separado del sistema de gestión de energía (EMS). Esto
es para mayor claridad; los dos podrían, por supuesto, ser incorporados en un solo sistema, y uno
podría imaginar aparatos que quieren comunicarse con sus fabricantes que sean compatibles
tanto con una interfaz Han y una interfaz Wi-Fi en lugar de en función del router. Estas son todas
las decisiones de diseño del fabricante.
A.1.1 . HAN enrutamiento
La HAN puede ser visto como la comunicación con los dos tipos de redes no-HAN. Uno de ellos es
el hogar de LAN, que a su vez puede ser conectado a Internet y, en general, ya sea obtendrá su
prefijo de la ISP aguas arriba o utilizar un auto-generado único direccionamiento local (ULA). Otra
es NAN de la utilidad, que a través de una ESI proporciona conectividad utilidad para la HAN; en
este caso la HAN será abordado por un auto-generado ULA (nota, sin embargo, que en algunos
casos ESI también puede proporcionar un prefijo a través de DHCP [
RFC3315 ]). Además, los Han tendrá

direcciones locales de vínculo que se pueden utilizar entre nodos vecinos. En general, un HAN
estará compuesto de dos otros 802.15.4, 802.11, y posiblemente redes.
El ESI es un nodo en la red residencial del usuario, y no suelen proporcionar servicios de

reenvío de paquetes o cortafuegos de estado entre el HAN y la red (s) de utilidad. En general,
la ESI es un nodo en la red doméstica; en algunos casos, el medidor puede actuar como el
ESI. Sin embargo, el ESI debe ser capaz de comprender que la mayoría de las redes
domésticas no están habilitadas 802.15.4 (más bien, son típicamente
Redes 802.11), y que debe ser capaz de establecer redes ad hoc entre varios sensores en el hogar
(por ejemplo, entre el medidor y decir, un termostato) en el caso de que no haya otras redes
disponibles.
A.1.2 . Seguridad HAN
En cualquier red, tenemos una variedad de amenazas y una variedad de posibles

mitigaciones. Estos incluyen, como mínimo:
Capa de enlace: ¿Por qué es su máquina capaz de hablar en mi red? Los SSID WiFi utilizan a
menudo alguna forma de control de acceso autenticado, que puede ser un simple mecanismo de
contraseña cifrada o puede utilizar una combinación de cifrado y autenticación + EAP-TLS IEEE
802.1X /

Autorización para asegurarse de que sólo las personas autorizadas comunicantes pueden usarlo. Si una LAN
tiene un router conectado, el router también puede implementar un cortafuegos para filtrar los accesos remotos.
Capa de red: Teniendo en cuenta que su máquina está autorizado el acceso a mi red, ¿por qué su
máquina hablando con mi máquina? IPsec es una forma de asegurar que los ordenadores que se
pueden conectar a una red se les permite hablar entre sí, también puede cumplir la
confidencialidad, y puede proporcionar servicios VPN para hacer que un dispositivo o red parecen
ser parte de una red remota.
Aplicación: Teniendo en cuenta que su máquina está autorizado el acceso a mi red y mi

máquina, ¿por qué es su aplicación hablando con mi solicitud? El hecho de que el equipo y
la mía se les permite hablar para algunas aplicaciones no significa que se les permite para
todas las aplicaciones. (D) TLS, https, y otros mecanismos permiten una aplicación para
imponer controles de aplicación a aplicación similares a los controles de capa de red
proporcionados por IPsec.
Aplicación remota: ¿Cómo sé que los datos que he recibido es que los datos que envió? Especialmente
en aplicaciones como el correo electrónico, donde los datos pasa a través de una serie de
intermediarios que uno puede o no realmente quieren munging ella (¿cuántas veces has visto una URL
roto por un servidor de correo?), Disponemos de herramientas (DKIM, S / MIME y W3C firmas XML
para nombrar unos pocos) que proporcionan no repudio y la verificación de la integridad. Esto también
puede tener ramificaciones legales: si un registro de la lectura del contador se va a utilizar en la
facturación, y la factura se disputa en los tribunales, uno podría imaginar la cancha con ganas prueba
de que el registro de hecho vino de ese metro en ese momento y contenido esos datos.
la seguridad específica de la aplicación: Además, las aplicaciones a menudo proporcionan servicios de

seguridad de su cuenta. El hecho de que pueda acceder a un sistema de archivos, por ejemplo, no quiere
decir que estoy autorizado para acceder a todo lo que contiene; el sistema de archivos también puede
impedir que mi acceso a algunos de sus contenidos. Los protocolos de enrutamiento como BGP están
obsesionados con la pregunta "¿qué declaraciones que mi pares hecho estoy dispuesto a creer", y
protocolos de monitoreo como SNMP pueden no estar dispuestos a responder todas las preguntas que se
les pide, dependiendo de la configuración de acceso.
Los dispositivos de la HAN quieren acceso controlado a la red local de que se trate, por razones
obvias. Además, debe haber alguna forma de autenticación mutua entre dispositivos - el
controlador de la lámpara va a querer saber que el interruptor de la luz diciendo que cambie de
estado es el interruptor de la luz derecha, por ejemplo. El EMS también puede querer autenticación
fuerte de accesos - los padres pueden no querer a los niños

cambiar la configuración, y si bien la utilidad y el cliente se conceden de forma rutinaria

el acceso, otras partes (en especial los partidos con intención criminal) deben ser
excluidos.
A.2 . Modelo 1: IAM con dominios separados
Con el fondo dada en Anexo A.1 , ahora podemos discutir el uso

de IP (IPv4 o IPv6) en el IAM.
En este primer modelo, considere los tres dominios de la Figura 6 a ser literalmente dominios
administrativos separados, potencialmente operados por diferentes entidades. Por ejemplo, la
NAN podría ser una red WiMAX operado por un operador de telecomunicaciones tradicional, la
red de la utilidad (incluyendo el colector) es su propia, y la red residencial es operado por el
residente. En este modelo, mientras que las comunicaciones entre el colector y el medidor son
normales, la utilidad no tiene otro acceso a los aparatos en el hogar, y el colector no lo hace
directamente hacia delante los mensajes de la NAN aguas arriba.
En este caso, como se muestra en la Figura 7, tendría más sentido para el diseño del colector, el
medidor y el SME como anfitriones en la NAN -Diseño como sistemas cuyas aplicaciones pueden
originar y terminar sesiones de intercambios o en el NAN, pero el tráfico no hacia adelante desde o
hacia otros dispositivos.
En tal configuración, respuesta a la demanda tiene que ser realizada por tener el SME aceptar mensajes
tales como señales de los precios de la "parte superior del poste", aplique alguna forma de política, y
luego orquestar acciones dentro de la casa. Otra posibilidad es que el SME comunicarse con el ESI se
encuentra en el medidor. Si el termostato tiene una alta demanda y baja demanda de configuración (día /
noche o por la mañana / día / tarde / noche), respuesta a la demanda podría dar lugar a que se mueva a
una posición menor demanda, y el SME también puede desactivar los circuitos especificados en el hogar
de disminuir la iluminación.
En este escenario, la calidad de servicio (QoS) problemas surgen cuando los informes, mensajes de
prioridad alta se deben enviar a través del colector a la casa; Si el colector está ocupada sondeo de los
metros o hacer alguna otra tarea, la aplicación no puede ceder el control del procesador a la aplicación
que brinda servicio al mensaje. Claramente, esto es o bien una aplicación o un problema del sistema
operativo; aplicaciones deben ser diseñados de una manera que no bloquea mensajes de prioridad alta.
El colector también tiene que utilizar los servicios de NAN apropiadas, si es que existen, para
proporcionar la calidad de servicio que necesita NAN. Por ejemplo, si WiMax está en uso, puede utilizar
un servicio a nivel de rutina para los intercambios normales, pero un servicio de mayor prioridad para
estos mensajes.

A.3 . Modelo 2: IAM con Barrio acceso al hogar
En este segundo modelo, imaginemos que la utilidad accede directamente a los artefactos dentro de los
Han. En lugar de esperar un EMS para responder a las señales de precios en respuesta a la demanda, se
manda directamente dispositivos como aparatos de aire acondicionado para cambiar de estado, o lanza
relés en circuitos o dentro de la casa.
+ ----------+ + --+ + --+ + --+

| metros | | D1 | | D2 | | D3 |
+ -----+ ----+ + + -+ + + -+ + + -+
| | | |
- - - - + - + - - - - - - - + - - - - + - - - - + - - - - IEEE 802.15.4
|
+ --+ ---+
| + - - - - - - / NAN ------ |
Router | |
+ - - - - - - / ------ banda ancha residencial
+ --+ ---+
|
- - - - + - - + - - - - - - + - - - - + - - - - + - - - - IEEE P1901
| | | |
+ -+ -+ + + -+ + + -+ + + -+
| Ccsme | | D4 | | D5 | | D6 |
+ ---+ + --+ + --+ + --+
Figura 8: Home Area Network
En este caso, como se muestra en la Figura 8, el medidor y EMS actúan como hosts de la HAN,
y hay un enrutador entre el HAN y la NAN.
Como uno puede imaginar, hay consideraciones de seguridad graves en este modelo. El
tráfico entre la NAN y la red de banda ancha residencial debe ser filtrada, y las cuestiones
planteadas en Apéndice A.1.2
asumir un nuevo nivel de significado. Una de las mayores amenazas puede ser un legal o al menos
un problema de relaciones públicas; Si la utilidad deshabilita intencionalmente un circuito de una
forma o en un momento que amenaza la vida (máquina de diálisis de riñón del residente es en él, o un
respirador, por ejemplo), la materia podría hacer que los papeles. El acceso no autorizado podría ser
parte de travesuras juveniles u otras cosas así. Así que uno realmente quiere los aparatos sólo por
obedecer órdenes bajo estrictos controles de autenticación / autorización.
Además de las cuestiones planteadas en QoS Apéndice A.2 , ahí está el

posibilidad de hacer cola problemas en el router. En tal caso, los datagramas IP deben utilizar
probablemente la baja latencia Clase de Servicio de Datos

descrito en [ RFC4594 ], Y dejar que el resto del tráfico utilizar la norma

La clase de servicio u otras clases de servicio.
A.4 . Modelo 3: Collector es un router IP
En este tercer modelo, la relación entre la NAN y el HAN es o bien como en

Apéndice A.2 o Apéndice A.3 ; lo que es diferente es que
el colector puede ser un router IP. Además de cualquier actividad autónoma que
está haciendo, reenvía el tráfico como un router IP en algunos casos.
Análogo a Apéndice A.3 , hay consideraciones de seguridad graves

en este modelo. El tráfico se reenvía debe ser filtrada, y las cuestiones planteadas en
Apéndice A.1.2 asumir un nuevo nivel de significado - pero
esta vez en la unidad central de servicios públicos. El acceso no autorizado es probablemente similar a
otros ataques motivados financieramente que pasan en Internet, pero se supone que iba a venir con los
productos en los Han que han sido cooptados de alguna manera. Uno realmente quiere los aparatos
sólo por obedecer órdenes bajo estrictos controles de autenticación / autorización.
Además de las cuestiones planteadas en QoS Apéndice A.2 , ahí está el

posibilidad de hacer cola problemas en el colector. En tal caso, los datagramas IP deben utilizar
probablemente la clase baja latencia del servicio de datos se describe en [
RFC4594 ], Y dejar que el resto del tráfico utilizar la norma
La clase de servicio u otras clases de servicio.
De los autores Direcciones
Fred panadero Cisco

Systems
Santa Bárbara, California 93117 EE.UU.
EMail: fred@cisco.com
David Meyer Cisco

Systems
Eugene, Oregon 97403 EE.UU.
EMail: dmm@cisco.com

Rfc6272 en Es

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Rfc6272 en Es

Enviado por

Direitos autorais:

Formatos disponíveis

Internet Engineering Task Force (IETF) F.

Protocolos de Internet para la red inteligente

Condición de este memo

Este documento es un producto de la Internet Engineering Task Force (IETF). Representa el

Este documento está sujeto a BCP 78 y Legal de la IETF Trust

Baker & Meyer informativo [Página 1]

3.1.4 . Aplicación de Seguridad de nivel. . . . . . . . . . . . . . 17

Baker & Meyer informativo [Página 2]

3.2.5 . IPv6 reenvío de multidifusión y enrutamiento. . . . . . . . 27

A.4 . Modelo 3: Collector es un router IP. . . . . . . . . . . . 66

Baker & Meyer informativo [Página 3]

En palabras de Wikipedia [ Red inteligente ]:

Esa descripción se centra en las implicaciones de la tecnología de redes inteligentes en el hogar

Baker & Meyer informativo [Página 4]

El protocolos de Internet (IPS) ofrece opciones para numerosos componentes

o Requisitos para hosts de Internet - Niveles de Comunicación [ RFC1122 ],

o Requisitos para hosts de Internet - Aplicación y soporte [

o Requisitos para IP versión 4 [Routers RFC1812 ], Y

Requisitos o IPv6 del nodo [ RFC4294 ].

En el momento de escribir estas líneas, RFC 4294 está en proceso de ser

o Sección 2 describe la arquitectura de Internet y su conjunto de protocolos.

o Por último, Sección 4 ofrece una visión general de la empresa

Baker & Meyer informativo [Página 5]

2 . La suite de protocolo de Internet

Antes de enumerar la lista de protocolos de Internet correspondientes a la Red Inteligente,

2.1 . Capas de protocolo de Internet

Figura 1: El modelo de referencia ISO OSI

La estructura del modelo de referencia de Internet se muestra en la Figura 2.

Baker & Meyer informativo [Página 6]

Figura 2: El Modelo de Referencia Internet

En el modelo de Internet, la aplicación, capas de presentación y de sesión se comprime en

Baker & Meyer informativo [Página 7]

El término "transporte" es quizás uno de los conceptos más confusos en la arquitectura de

Además, las responsabilidades de un protocolo de capa de transporte específico típicamente incluyen la

La función principal de la capa de red es identificar un destino remoto y entregar datos a la

Baker & Meyer informativo [Página 8]

2.1.3.1 . protocolo de Internet

2.1.3.2 . Las redes de capa inferior

2.1.4 . Capas de medios de comunicación: Física y Enlace

2.2 . Temas de seguridad

Baker & Meyer informativo [Página 9]

a menudo se ha mitigado mediante funciones de seguridad existentes ya especificados para el protocolo, o

2.2.1 . Seguridad de la capa física y de enlace de datos

Baker & Meyer informativo [Página 10]

2.2.2 . Red, transporte y aplicación de seguridad de capa

2. Integridad: proteger contra cambios no autorizados en los intercambios, incluyendo tanto el

3. Disponibilidad: Asegúrese de que el recurso es accesible mediante la mitigación de

Baker & Meyer informativo [Página 11]

A esto le sumamos la autenticidad, la cual requiere que los compañeros de comunicación

Baker & Meyer informativo [Pagina 12]

2.3 . Infraestructura de red

2.3.1 . Sistema de nombres de dominio (DNS)

La función principal DNS es traducir nombres a direcciones IP numéricas. Si bien esto no es

2.3.2 . Administración de redes

Otro aspecto de la gestión de red es el aprovisionamiento inicial y la configuración de

Baker & Meyer informativo [Página 13]

En esta sección, después de haber establecido brevemente la arquitectura IP y algunos de los

3.1 . Caja de herramientas de seguridad

3.1.1 . Autenticación, autorización y contabilidad (AAA)

Baker & Meyer informativo [Página 14]

Protocolo de autenticación (EAP [ RFC4017 ]) Como un recipiente para encapsular

RFC5191 ] Y IEEE 802.1X [ IEEE802.1X ].

3.1.2 . Seguridad de la capa de red