1. RFC2373 - IP versión 6 frente a la
arquitectura
Network Working Group R. Hinden
Petición de Comentarios: 2373 Nokia
Obsoletos: 1884 S. Deering
Categoría: normas de Cisco Systems
Julio 1998
IP versión 6 frente a la arquitectura
Estado de este documento
Este documento especifica un protocolo de normas de Internet para la
Comunidad de Internet, y solicita debate y sugerencias para
mejoras. Por favor refiérase a la edición actual de la "Internet
Diario Protocolo de Normas "(STD 1) para la normalización de estado
y la situación de este protocolo. La distribución de este memorándum
es ilimitada.
Copyright Notice
Copyright (C) The Internet Society (1998). Todos los derechos
reservados.
Resumen
Esta especificación define la arquitectura de direccionamiento de la
IP de
La versión 6 del protocolo [IPv6]. El documento incluye el
direccionamiento IPv6
modelo, las representaciones de texto de direcciones IPv6, la
definición de IPv6

2. las direcciones unicast, direcciones anycast, y la dirección de
multidifusión, y un
Direcciones necesarias nodo IPv6.
Tabla de contenidos
1. Introducción ................................................. 2
2. Direccionamiento
IPv6 .............................................. 2
2.1 Abordar Modelo ......................................... 3
2.2 Representación de texto de
direcciones ......................... 3
2.3 Representación de texto de Dirección
Prefijos .................. 5
2.4 Dirección Representación de
tipo .............................. 6
2.5 Direcciones Unicast ........................................ 7
2.5.1 Identificadores de
interfaz ................................ 8
2.5.2 La dirección no
especificada .............................. 9
2.5.3 La dirección de bucle
invertido ................................. 9
2.5.4 direcciones IPv6 con direcciones IPv4 Embedded .........
10
2.5.5 Direcciones NSAP ...................................... 10
2.5.6 Direcciones IPX ....................................... 10
2.5.7 Aggregatable Global Direcciones Unicast ............... 11
2.5.8 Local de usar direcciones IPv6
Unicast .................... 11
2.6 Direcciones Anycast ....................................... 12

3. 2.6.1 Obligatorio Anycast Dirección ............................
13
2.7 Direcciones Multicast ..................................... 14
2.7.1 predefinidas Direcciones Multicast .....................
15
2.7.2 La asignación de nuevas direcciones IPv6
Multicast .......... 17
Direcciones Requerido 2,8 de un nodo .............................
17
3. Consideraciones de
seguridad ..................................... 18
Apéndice A: Creación de EUI-64 interfaz basada en identificadores de
19 ........
Apéndice B: ABNF Descripción de representaciones de texto ...........
22
ANEXO C: CAMBIOS DEL RFC-1884 .............................. 23
REFERENCIAS ................................................. .... 24
Direcciones de los
autores ............................................. 25
Declaración Completa de
Copyright ....................................... 26
1.0 INTRODUCCIÓN
Esta especificación define la arquitectura de direccionamiento de la
IP de
La versión 6 del protocolo. Se incluye una descripción detallada de
la
Actualmente, formatos definidos por la dirección de IPv6 [IPv6].
Los autores desean agradecer la contribución de Paul

4. Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
, Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
y Sue Thomson.
Las palabras clave "DEBE", "NO DEBE", "REQUERIDO", "SE", "NO",
"DEBE", "NO", "recomendada", "MAYO", y "OPCIONAL" en este
documento se han de interpretar como se describe en [RFC 2119].
2,0 direccionamiento IPv6
Las direcciones IPv6 son identificadores de 128 bits para interfaces
y conjuntos de
interfaces. Hay tres tipos de direcciones:
Unicast: Un identificador para una única interfaz. Un paquete
enviado a
una dirección unicast se entrega a la interfaz de
identificadas por esa dirección.
Anycast: Un identificador para un conjunto de interfaces
(típicamente
pertenecientes a diferentes nodos). Un paquete enviado
a una
dirección anycast es entregado a una de las interfaces
de
identificadas por esa dirección (la más cercana "," uno,
de acuerdo
para medir los protocolos de enrutamiento 'de
distancia).

5. Multicast: un identificador para un conjunto de interfaces
(típicamente
pertenecientes a diferentes nodos). Un paquete enviado
a una
dirección multicast es entregado a todas las interfaces
identificadas por esa dirección.
No hay direcciones de difusión en IPv6, su función se
sustituida por las direcciones de multidifusión.
En este documento, los campos de direcciones se les da un nombre
específico, para los
"ejemplo de abonado". Cuando se utiliza este nombre con el término
"identificación" de
identificador después del nombre (por ejemplo, "abonado ID"), se
refiere a la
contenido del campo nombre. Cuando se utiliza el término "prefijo"
(por ejemplo, el prefijo "suscriptor") se refiere a todos los de la
dirección hasta el
incluyendo este campo.
En IPv6, todos los ceros y todas las que son valores válidos para
cualquier campo,
a menos que específicamente excluidos. En concreto, los prefijos
pueden contener
con valor cero los campos o al final en ceros.
2.1 Modelo de direccionamiento
Direcciones IPv6 de todos los tipos se asignan a interfaces, no
nodos.

6. Una dirección IPv6 unicast se refiere a una sola interfaz. Puesto
que cada
interfaz pertenece a un solo nodo, cualquiera de las interfaces que
nodo '
las direcciones unicast puede ser utilizado como un identificador
para el nodo.
Todas las interfaces tienen que tener al menos un link-local unicast
dirección (ver sección 2.8 para más direcciones de obligatorio). Un
única interfaz también se le puede asignar múltiples direcciones IPv6
de cualquier
(tipo unicast, anycast y multicast) o ámbito de aplicación. Las
direcciones unicast
con mayor alcance que el ámbito de aplicación de enlace no son
necesarios para las interfaces que
no se utilizan como origen o destino de los paquetes IPv6 o
procedentes de terceros vecinos. Esto a veces es conveniente para
punto a punto
interfaces. Hay una excepción a este modelo, abordando:
Una dirección unicast o un conjunto de direcciones unicast pueden
ser asignados a
múltiples interfaces físicas si la aplicación trata de la
múltiples interfaces físicas como una interfaz, cuando lo presente
a
de la capa de Internet. Esto es útil para carga compartida por
múltiples
interfaces físicas.
Actualmente IPv6 sigue el modelo de IPv4 que un prefijo de subred es
asociados con un enlace. Múltiples prefijos de subred pueden ser
asignados

7. para el mismo enlace.
2.2 Representación de texto de direcciones de
Hay tres formas convencionales para la representación de direcciones
IPv6 como
cadenas de texto:
1. La forma preferida es x: x: x: x: x: x: x: x, donde la "x" son
las
los valores hexadecimales de las ocho piezas de 16-bit de la
dirección.
Ejemplos:
FEDC: BA98: 7654:3210: FEDC: BA98: 7654:3210
1080:0:0:0:8:800:200 C: 417A
Tenga en cuenta que no es necesario escribir los ceros a la
izquierda en un
ámbito individual, pero debe haber al menos un número en cada
de campo (excepto en el caso descrito en 2.).
2. Debido a algunos métodos de asignación de ciertos estilos de IPv6
las direcciones, que será común para las direcciones que contienen
las cadenas largas
de bits a cero. Con el fin de hacer de la escritura que contiene
las direcciones de cero
bits más fácil una sintaxis especial que está disponible para
comprimir los ceros.
El uso de "::" indica múltiples grupos de 16-bits de ceros.

8. La "::" sólo puede aparecer una vez en una dirección. La "::"
también puede ser
utilizado para comprimir el principal y / o ceros a la derecha en
una dirección.
Por ejemplo las siguientes direcciones:
1080:0:0:0:8:800:200 C: 417A una dirección unicast
FF01: 0:0:0:0:0:0:101 una dirección de multidifusión
0:0:0:0:0:0:0:1 la dirección loopback
0:0:0:0:0:0:0:0 las direcciones, sin especificar
se puede representar como:
1080:: 8:800:200 C: 417A una dirección unicast
FF01:: 101 una dirección de multidifusión
:: 1, la dirección loopback
:: Las direcciones, sin especificar
3. Una forma alternativa de que a veces es más conveniente cuando se
trata
con un entorno mixto de IPv4 e IPv6 nodos es
x: x: x: x: x: x: dddd, donde la "x" son los valores hexadecimales
de la
las seis de orden superior 16-bit de piezas de la dirección, y el
'D's se
de los valores decimales de las cuatro de orden inferior 8-bit de
las piezas de la
dirección (representación estándar IPv4). Ejemplos:
0:0:0:0:0:0:13.1.68.3

9. 0:0:0:0:0: FFFF: 129.144.52.38
o en forma de comprimidos:
:: 13.1.68.3
:: FFFF: 129.144.52.38
2.3 Representación de texto de prefijos de direcciones
La representación de texto de prefijos de direcciones IPv6 es similar
a la
direcciones IPv4 manera prefijos se escriben en la notación CIDR.
IPv6
prefijo de la dirección está representado por la notación:
ipv6-address/prefix-length
dónde
ipv6-dirección es una dirección IPv6 en cualquiera de las
anotaciones que figuran
en la sección 2.2.
prefijo de longitud es un valor decimal que especifica cuántos de
los
más a la izquierda de bits contiguos de la
dirección de incluir
el prefijo.
Por ejemplo, las siguientes son representaciones legales de los 60-
bits

10. prefijo 12AB00000000CD3 (hexadecimal):
12AB: 0000:0000: CD30: 0000:0000:0000:0000 / 60
12AB:: CD30: 0:0:0:0 / 60
12AB: 0:0: CD30:: / 60
Los siguientes no son representaciones legales del prefijo de arriba:
12AB: 0:0: CD3/60 puede caer ceros a la izquierda, pero no ceros a
la derecha,
dentro de cualquier bloque 16-bit de la
dirección
12AB:: CD30/60 dirección a la izquierda de "/" se expande a
12AB: 0000:0000:0000:0000:000:0000: CD30
12AB:: CD3/60 dirección a la izquierda de "/" se expande a
12AB: 0000:0000:0000:0000:000:0000:0 CD3
Al escribir tanto una dirección de nodo y de un prefijo de que la
dirección de nodo
(por ejemplo, el prefijo de subred del nodo), los dos pueden
combinarse como sigue:
la dirección de nodo 12AB: 0:0: CD30: 123:4567:89 AB: CDEF
12AB y su número de subred: 0:0: CD30:: / 60
puede ser abreviada como 12AB: 0:0: CD30: 123:4567:89 AB: CDEF/60
2.4 Dirección Representación de tipo de
El tipo específico de una dirección IPv6 es indicado por los bits más

11. en la dirección. El campo de longitud variable que comprende estos
líderes
bits se le llama prefijo de formato (FP). La asignación inicial de
estos prefijos es el siguiente:
Prefijo de Fracción de la asignación de
(binario) del espacio de
direcciones
----------------------------------- -------- ------- ------
Reservados 0000 0000 1 / 256
Sin asignar 0000 0001 1 / 256
Reservado para la asignación NSAP 0000 001 1 / 128
Reservado para IPX Asignación 0000 010 1 / 128
Sin asignar 0000 011 1 / 128
Sin asignar 0000 1 1 / 32
Sin asignar 0001 1 / 16
Aggregatable Mundial Direcciones Unicast 001 1 / 8
Sin asignar 010 1 / 8
Sin asignar 011 1 / 8
Sin asignar 100 1 / 8
Sin asignar 101 1 / 8
Sin asignar 110 1 / 8
Sin asignar 1110 1 / 16
Sin asignar 1111 0 1 / 32
Sin asignar 1111 10 1 / 64
Sin asignar 1111 110 1 / 128
Sin asignar 1111 1110 0 1 / 512

12. Link-Local Direcciones Unicast 1111 1110 10 1 / 1024
El sitio local Direcciones Unicast 1111 1110 11 1 / 1024
Direcciones Multicast 1111 1111 1 / 256
Notas:
(1) La "dirección no especificada" (véase la sección 2.5.2), el
bucle de retorno
dirección (ver sección 2.5.3), y las direcciones IPv6 con
Las direcciones IPv4 Embedded (ver sección 2.5.4), se asignan
a cabo
del espacio prefijo 0000 0000 formato.
(2) El formato de los prefijos 001 a 111, excepto para la
multidifusión
Direcciones (1111 1111), están obligadas a tener de 64-bit
identificadores de interfaz en formato EUI-64. Vea la sección
2.5.1 para
definiciones.
Esta asignación apoya la asignación directa de la agregación de
direcciones, direcciones de uso local, y las direcciones de
multidifusión. El espacio es
para las direcciones de NSAP y direcciones IPX. El resto de la
espacio de direcciones es asignado para su uso futuro. Esto puede
ser usado para
la expansión del uso existente (por ejemplo, direcciones adicionales
agregables,
, etc) o de nuevos usos (por ejemplo, identificadores y localizadores
por separado). Quince

13. por ciento del espacio de direcciones es asignado inicialmente. El
resto
El 85% está reservado para uso futuro.
Las direcciones unicast se distinguen de las direcciones de
multidifusión por la
el valor del octeto de orden superior de las direcciones: un valor de
FF
(11111111) se identifica una dirección como una dirección de
multidifusión, y cualquier otro
valor identifica una dirección como una dirección unicast. Las
direcciones anycast
se toman desde el espacio de direcciones unicast, y no son
sintácticamente
distinguibles de las direcciones unicast.
2.5 Direcciones Unicast
Las direcciones unicast IPv6 se agregables con bits contiguos sabio
las máscaras similares a las direcciones IPv4 en la clase-less
Interdomain Routing
[CIDR].
Hay varias formas de asignación de direcciones unicast en IPv6,
incluido el mundial agregables dirección unicast global, el NSAP
, la dirección de la dirección IPX jerárquica, el sitio de la
dirección local, la
dirección local de vínculo, y la dirección IPv4 de acogida capaces.
Adicionales
los tipos de direcciones se puede definir en el futuro.

14. Los nodos IPv6 pueden tener un considerable conocimiento o poco de la
interna
la estructura de la dirección IPv6, dependiendo de la función del
nodo juega
(por ejemplo, de acogida frente a router). Como mínimo, un nodo
puede
consideran que las direcciones unicast (incluido el suyo propio) no
tienen ningún interno
estructura:
| 128 bits |
+------------------------------------------------- ----------------+
| Dirección de nodo |
+------------------------------------------------- ----------------+
Una gran cantidad ligeramente sofisticada (pero aún bastante simple)
puede
además, ser conscientes de prefijo de subred (es) para el enlace (s)
es
anexa a los mismos valores diferentes en diferentes direcciones puede
tener para
n:
| N bits | 128-n bits |
+------------------------------------------------+ ----------------+
| Prefijo de subred | ID de interfaz |
+------------------------------------------------+ ----------------+
Sigue albergando más sofisticados pueden ser conscientes de otros
jerárquica
límites en la dirección unicast. Aunque un router muy sencillo,
puede

15. no tienen conocimiento de la estructura interna de IPv6 unicast
direcciones, routers más general, tener conocimiento de uno o más
de las fronteras jerárquicas para la operación de rutas
protocolos. De los límites conocidos serán diferentes de router a
router,
dependiendo de las posiciones que el router tiene en la ruta
jerarquía.
2.5.1 Identificadores de interfaz de
Identificadores de interfaz en las direcciones unicast IPv6 se
utiliza para identificar
interfaces en un enlace. Están obligados a ser único en ese enlace.
También pueden ser únicos en un ámbito más amplio. En muchos casos,
una
identificador de interfaz será la misma que la interfaz de enlace -
dirección de la capa. El mismo identificador de interfaz puede ser
utilizado en múltiples
interfaces en un solo nodo.
Tenga en cuenta que el uso del mismo identificador de interfaz en
múltiples
interfaces de un solo nodo no afecta a la interfaz de
singularidad global o el identificador de cada uno de direcciones
IPv6 globales
singularidad creado utilizando el identificador de la interfaz.
En varios de los prefijos de formato (ver sección 2.4),
identificadores de interfaz de
están obligados a ser de 64 bits de longitud y que se construirá en
IEEE EUI-64

16. formato [EUI64]. EUI-64 identificadores de interfaz puede tener
global
alcance mundial, cuando un testigo está disponible (por ejemplo, IEEE
MAC de 48 bits) o puede
tener un alcance local, donde un símbolo mundial no está disponible
(por ejemplo, de serie
enlaces, al final del túnel, puntos, etc.) Es necesario que la "U"
poco
(Universal / bit locales en IEEE EUI-64 terminología) se invierte
cuando se
que forman el identificador de interfaz de la EUI-64. La "U" está
establecido el bit
a un (1) para indicar el alcance global, y se establece en cero (0)
para
indican ámbito local. Los tres primeros octetos en binario de un
EUI-64
identificador son los siguientes:
0 0 0 1 1 2
| 0 7 8 5 6 3 |
+----+----+----+----+----+----+
| cccc | CCUG | cccc | cccc | cccc | cccc |
+----+----+----+----+----+----+
escrito en bits de Internet estándar orden, donde "U" es el
locales poco universales, "g" es la persona o grupo de bits, y "C"
son las
bits de la Company_id. Apéndice A: "Creación de EUI-64 interfaz
basada en la
Identificadores "proporciona ejemplos de la creación de diferentes
EUI-64
identificadores de interfaz basada en.

17. La motivación para invertir la "U" poco la hora de formar la interfaz
de
identificador es hacer que sea fácil para los administradores del
sistema a la mano
identificadores configurar ámbito local, cuando tokens de hardware no
son
disponible. Esto se espera que sea el caso de enlaces de serie, al
final de túnel
puntos, etc La alternativa hubiera sido que éstos sean de la
forma 0200:0:0:1, 0200:0:0:2, etc, en lugar del mucho más simple:: 1,
:: 2, etc
El uso del bit universal / local en el IEEE EUI-64 identificador es
para permitir el desarrollo de la tecnología de futuro que puede
tomar ventaja de
identificadores de interfaz con alcance global.
Los detalles de la formación de los identificadores de interfaz se
definen en el
apropiadas "IPv6 sobre <link>" pliego de condiciones tales como "IPv6
sobre
Ethernet "[éter]," IPv6 sobre FDDI "[FDDI], etc
2.5.2 La dirección no especificada
La dirección 0:0:0:0:0:0:0:0 se llama la dirección especificada.
Ello
nunca debe ser asignado a cualquier nodo. Indica la ausencia de un
dirección. Un ejemplo de su uso es en el campo de Dirección de
Origen de

18. los paquetes IPv6 enviado por un host de inicialización antes de que
se ha aprendido
su propia dirección.
La dirección no especificada no debe utilizarse como dirección de
destino
de paquetes IPv6 o en los encabezados de enrutamiento de IPv6.
2.5.3 La dirección de bucle invertido de
La dirección unicast 0:0:0:0:0:0:0:1 se llama la dirección de bucle
invertido.
Puede ser utilizado por un nodo para enviar un paquete IPv6 a sí
mismo. Puede
nunca ser asignados a cualquier interfaz física. Puede ser pensado
como
se asocia con una interfaz virtual (por ejemplo, el bucle de retorno
interfaz).
La dirección de bucle invertido no debe ser utilizada como dirección
de origen en IPv6
paquetes que se envían fuera de un solo nodo. Un paquete IPv6 con
una dirección de destino de bucle invertido no debe ser enviado fuera
de una
solo nodo, y nunca debe ser remitido por un router IPv6.
2.5.4 direcciones IPv6 con direcciones IPv4 Embedded
Los mecanismos de transición de IPv6 [TRAN] incluyen una técnica para
ordenadores
y los routers de forma dinámica los paquetes IPv6 en túnel de
enrutamiento de IPv4

19. infraestructura. Los nodos IPv6 que utilizan esta técnica son
asignados
direcciones IPv6 unicast especiales que llevan a una dirección IPv4
en el bajo
32-bits de orden. Este tipo de dirección que se denomina un "IPv4
compatible
Dirección IPv6 "y tiene el formato:
| 80 bits | 16 | 32 bits |
+--------------------------------------+---------- ----------------+
| 0000 .............................. 0000 | 0000 | dirección IPv4 |
+--------------------------------------+----+----- ----------------+
Un segundo tipo de dirección IPv6 que tiene una dirección IPv4
incrustado se
También se define. Esta dirección se utiliza para representar las
direcciones de
IPv4 sólo los nodos (los que * no * soporte de IPv6) como direcciones
IPv6.
Este tipo de dirección que se denomina un "mapeado de direcciones
IPv4-IPv6" y ha
el formato:
| 80 bits | 16 | 32 bits |
+--------------------------------------+---------- ----------------+
| 0000 .............................. 0000 | FFFF | dirección IPv4 |
+--------------------------------------+----+----- ----------------+
2.5.5 Direcciones NSAP
Esta asignación de dirección NSAP en direcciones IPv6 se define en el

20. [NSAP]. Este documento recomienda que los ejecutores de la red que
han
previsto o que se instale una inspección in situ NSAP abordar plan, y
que deseen
implementar o la transición al IPv6, debe rediseñar un IPv6 nativo
plan de direccionamiento para satisfacer sus necesidades. Sin
embargo, también define un conjunto
de mecanismos para el apoyo de OSI NSAP a tratar en IPv6
red. Estos mecanismos son los que debe utilizarse si tales
apoyo es necesario. Este documento también define una asignación de
IPv6
direcciones en el formato de dirección OSI, si ello fuera necesario.
2.5.6 Direcciones IPX
Esta asignación de la dirección IPX en direcciones IPv6 es la
siguiente:
| 7 | 121 bits |
+-------+----------------------------------------- ----------------+
| 0000010 | a ser definida |
+-------+----------------------------------------- ----------------+
El proyecto de definición, la motivación y el uso son objeto de
estudio.
2.5.7 Aggregatable Global Unicast Direcciones
El mundial agregables dirección unicast global se define en [Aggr].
Este formato de dirección está diseñado para apoyar tanto el
proveedor actual

21. basado en la agregación y un nuevo tipo de agregación llamados
intercambios.
La combinación permitirá la agregación de enrutamiento eficaz, tanto
para
los sitios que se conectan directamente a los proveedores y que se
conectan a
intercambios. Sitios tendrán la opción de conectarse a cualquier
tipo de
punto de agregación.
El agregables formato de la dirección global de IPv6 unicast es la
siguiente:
| 3 | 13 | 8 | 24 | 16 | 64 bits |
+--+-----+---+--------+--------+------------------ --------------+
| FP | TLA | RES | NLA | SLA | Interface ID |
| | ID | | ID | ID | |
+--+-----+---+--------+--------+------------------ --------------+
Dónde
Formato 001 Prefijo (3 bits) para Aggregatable Global
Las direcciones unicast
TLA ID Top-Level Aggregation Identificador
RES Reservado para uso futuro
NLA ID próximo nivel de agregación Identificador
SLA ID Site-nivel de agregación Identificador
INTERFACE ID Interface Identifier
El contenido, el tamaño de los campos, y reglas de asignación se
definen en el
[Aggr].

22. 2.5.8 Local-Usa IPv6 Unicast Direcciones
Hay dos tipos de uso local unicast direcciones definidas. Estos
se enlace local y el sitio local. El enlace local es para uso en un
único
enlace y el sitio local es para uso en un solo sitio. Link-Local
las direcciones tienen el siguiente formato:
| 10 |
Bits | | 54 bits | 64 bits |
+----------+-------------------------+------------ ----------------+
| 1111111010 | 0 | ID de interfaz |
+----------+-------------------------+------------ ----------------+
Direcciones de enlace local están diseñados para ser utilizados para
hacer frente a una
solo enlace para fines tales como la auto-configuración de la
dirección, el vecino de
descubrimiento, o cuando no hay routers están presentes.
Routers no debe presentar ninguna relación con los paquetes de
fuentes locales o
direcciones de destino a otros enlaces.
Las direcciones locales del sitio tienen el siguiente formato:
| 10 |
Bits | | 38 bits | 16 bits | 64 bits |
+----------+-------------+-----------+------------ ----------------+
| 1111111011 | 0 | ID subred | ID de interfaz |
+----------+-------------+-----------+------------ ----------------+

23. Las direcciones locales de la web están diseñados para ser utilizados
para abordar dentro de la
un sitio sin la necesidad de un prefijo global.
Routers no debe reenviar ningún paquete con el sitio de origen local
o de
direcciones de destino fuera del sitio.
2.6 Direcciones Anycast
Una dirección IPv6 anycast es una dirección que se asigna a más de
una interfaz (por lo general pertenecientes a diferentes nodos), con
el
propiedad de que un paquete enviado a una dirección anycast se dirige
a la
"más cercano" con interfaz de esa dirección, de acuerdo a la ruta
medida de los protocolos "de distancia.
Las direcciones anycast son asignados a partir del espacio de
direcciones unicast, utilizando
cualquiera de los formatos de dirección definida unicast. Así, las
direcciones anycast
son sintácticamente indistinguibles de las direcciones unicast.
Cuando un
dirección unicast es asignada a más de una interfaz, convirtiendo así
a
que en una dirección anycast, los nodos para que la dirección es
asignado debe ser configurado explícitamente para saber que es un
anycast
dirección.

24. Para cualquier dirección anycast asignadas, no hay más tiempo de P
prefijo de la dirección
que identifica a la región topológico en el que todas las interfaces
pertenecientes a esa dirección anycast residen. Dentro de la región
identificados por P, cada miembro del conjunto de anycast debe ser
objeto de publicidad como
una entrada independiente en el sistema de enrutamiento (comúnmente
conocido como
"ruta de host"); fuera de la región identificado por P, la anycast
dirección puede ser agregada en el anuncio de enrutamiento para el
prefijo
P.
Tenga en cuenta que en el peor de los casos, el prefijo P de un
conjunto anycast puede ser
el prefijo nulo, es decir, los miembros de la serie puede no tener
topológico
localidad. En ese caso, la dirección anycast debe ser anunciada como
una
de entrada de enrutamiento separadas a lo largo de toda la Internet,
que presenta la
un límite de descamación intensa de la cantidad de tales "global"
establece anycast puede ser
apoyo. Por lo tanto, se espera que el apoyo a anycast mundial
conjuntos no puede estar disponible o muy restringida.
Uno de los usos previstos de las direcciones anycast es identificar
el conjunto de los
routers que pertenecen a una organización que provee servicios de
Internet.

25. Estas direcciones pueden utilizarse como direcciones intermedias en
IPv6
De enrutamiento de cabecera, a causa de un paquete para ser entregado
a través de un particular,
la agregación o la secuencia de agregaciones. Algunos otros usos
posibles
son identificar el conjunto de enrutadores conectados a una subred
particular,
o el conjunto de routers de prestación de entrada en una ruta
particular,
dominio.
Hay poca experiencia con el uso generalizado de Internet arbitraria
de
Las direcciones anycast, y algunas complicaciones y peligros
conocidos cuando
utilizarlos en su generalidad completa [ANYCST]. Hasta que más
experiencia
Se ha adquirido y las soluciones acordadas para los problemas, la
Se imponen las siguientes restricciones sobre las direcciones IPv6
anycast:
o una dirección anycast no debe utilizarse como dirección de
origen de una
Paquetes IPv6.
o una dirección anycast no debe ser asignada a un host IPv6, que
es decir, puede ser asignado a un router IPv6 solamente.
2.6.1 Obligatorio Anycast Dirección

26. La dirección de anycast de subred router está predefinido. Su
formato es como
siguiente:
| N bits | 128-n bits |
+------------------------------------------------+ ----------------+
| Prefijo de subred | 00000000000000 |
+------------------------------------------------+ ----------------+
El "prefijo de subred" en una dirección anycast es el prefijo que
identifica un enlace específico. Esta dirección anycast es
sintácticamente
lo mismo que una dirección unicast de una interfaz en el enlace con
la
identificador de interfaz a cero.
Los paquetes enviados a la dirección de subred Router anycast se
entregarán
a un enrutador de la subred. Todos los routers son necesarias para
apoyar la
Subred direcciones anycast Router para las subredes que se han
interfaces.
La dirección de anycast de subred router está destinado a ser
utilizado para
aplicaciones en las que un nodo necesita comunicarse con uno de un
conjunto de
routers en una subred remota. Por ejemplo, cuando un host móvil debe
comunicarse con uno de los agentes móviles en su casa "," subred.
2.7 Direcciones Multicast

27. Una dirección IPv6 multicast es un identificador para un grupo de
nodos. Un
nodo puede pertenecer a cualquier número de grupos de multidifusión.
Multicast
las direcciones tienen el siguiente formato:
| 8 | 4 | 4 | 112 bits |
+------ -+----+----+------------------------------- --------------+
| 11111111 | FLGS | SCOP | ID de grupo |
+--------+----+----+------------------------------ ---------------+
11111111 al comienzo de la dirección identifica la dirección como
ser una dirección de multidifusión.
+-+-+-+-+
FLGS es un conjunto de 4 banderas: | 0 | 0 | 0 | T |
+-+-+-+-+
El alto las banderas de orden 3 están reservadas, y debe ser
inicializado a
0.
T = 0 indica una permanente asignado ( "bien conocidos") de
multidifusión
la dirección, asignado por la Internet global de numeración de
la autoridad.
T = 1 indica un no permanente asignado ( "transitorio")
dirección de multidifusión.
SCOP es un 4-multicast valor del bit alcance para limitar el
alcance de la

28. el grupo de multidifusión. Los valores son:
0 Reservado
1 nodo de ámbito local -
2 link-local alcance
3 (sin asignar)
4 (sin asignar)
5 sitio ámbito local
6 (sin asignar)
7 (sin asignar)
8 Organización ámbito local
9 (sin asignar)
A (sin asignar)
B (sin asignar)
C (sin asignar)
D (sin asignar)
E alcance mundial
F reservados
ID de grupo identifica el grupo multicast, ya sea permanente o
transitorio, en el ámbito determinado.
El "significado" de una dirección de multidifusión permanentemente
asignado es
independiente del valor de alcance. Por ejemplo, si los servidores
"NTP
grupo "se le asigna una dirección multicast permanente con un ID de
grupo de
101 (hexadecimal), entonces:

29. FF01: 0:0:0:0:0:0:101, todos los servidores NTP en el mismo nodo
que la
remitente.
FF02: 0:0:0:0:0:0:101, todos los servidores NTP en el mismo enlace
que la
remitente.
FF05: 0:0:0:0:0:0:101, todos los servidores NTP en el mismo sitio
que el
remitente.
FF0E: 0:0:0:0:0:0:101, todos los servidores NTP en el Internet.
No permanente asignado direcciones multicast sólo tienen sentido
dentro de un ámbito determinado. Por ejemplo, un grupo identificado
por la no -
lugar permanente, local de FF15 dirección de multidifusión:
0:0:0:0:0:0:101 en un
el sitio no tiene relación con un grupo usando la misma dirección en
un
sitio diferente, ni a un grupo no permanentes utilizando el mismo
grupo de identificación
con diferente alcance, ni a un grupo permanente con el mismo grupo
ID.
Las direcciones de multidifusión no deben ser utilizados como fuente
de las direcciones en IPv6
paquetes o aparecer en cualquier cabecera de enrutamiento.
2.7.1 predefinidas direcciones multicast

30. Las siguientes direcciones de multidifusión conocidos son pre-
definidos:
Reservados Direcciones Multicast: FF00: 0:0:0:0:0:0:0
FF01: 0:0:0:0:0:0:0
FF02: 0:0:0:0:0:0:0
FF03: 0:0:0:0:0:0:0
FF04: 0:0:0:0:0:0:0
FF05: 0:0:0:0:0:0:0
FF06: 0:0:0:0:0:0:0
FF07: 0:0:0:0:0:0:0
FF08: 0:0:0:0:0:0:0
FF09: 0:0:0:0:0:0:0
FF0A: 0:0:0:0:0:0:0
FF0B: 0:0:0:0:0:0:0
FF0C: 0:0:0:0:0:0:0
FF0D: 0:0:0:0:0:0:0
FF0E: 0:0:0:0:0:0:0
FF0F: 0:0:0:0:0:0:0
Las direcciones multicast arriba son reservados y nunca se
asignados a cualquier grupo de multidifusión.
Todas las direcciones de nodos: FF01: 0:0:0:0:0:0:1
FF02: 0:0:0:0:0:0:1
Las direcciones de multidifusión por encima de identificar el grupo
de todos los nodos IPv6,
dentro del ámbito 1 (nodo local) o 2 (Link-Local).
Todas las direcciones Routers: FF01: 0:0:0:0:0:0:2

31. FF02: 0:0:0:0:0:0:2
FF05: 0:0:0:0:0:0:2
Las direcciones de multidifusión por encima de identificar el grupo
de todos los routers IPv6,
dentro del ámbito 1 (nodo local), 2 (Link-Local) o 5 (site-local).
Solicitados-Node Dirección: FF02: 0:0:0:0:1: FFXX: XXXX
La dirección de multidifusión arriba se calcula en función de un nodo
unicast y direcciones anycast. El solicitó la dirección de
multidifusión de nodo
está formado por tomar la bits de orden 24 de la dirección (unicast o
anycast) y anexar los bits para el prefijo
FF02: 0:0:0:0:1: FF00:: / 104 resulta en una dirección de
multidifusión en la
rango
FF02: 0:0:0:0:1: FF00: 0000
para
FF02: 0:0:0:0:1: FFFF: FFFF
Por ejemplo, la multidifusión de nodo solicitado a la dirección
correspondiente
la dirección IPv6 4037:: 01:800:200 E: 8C6C es FF02:: 1: FF0E: 8C6C.
IPv6
las direcciones que sólo difieren en la bits de alto orden, por
ejemplo, debido a la
Para varios de alta prefijos asociados con formaciones diferentes,

32. se asignarán a la misma dirección de nodo solicitado reduciendo así
la
número de direcciones de multidifusión un nodo debe unirse.
Un nodo es necesario para calcular y unirse a la Solicitada
asociados-Node
direcciones de multidifusión y unidifusión para cada dirección
anycast es
asignado.
2.7.2 Asignación de nuevas direcciones IPv6 Multicast
El enfoque actual [éter] para asignar direcciones IPv6 multicast en
IEEE 802 direcciones MAC toma la orden bajo 32 bits del IPv6
dirección de multidifusión y la utiliza para crear una dirección MAC.
Tenga en cuenta que
Redes Token Ring se manejan de manera diferente. Esto se define en
[Token]. ID de grupo es menor o igual a 32 bits se generan
únicas direcciones MAC. Debido a esta nueva dirección IPv6 multicast
debe ser asignado de manera que el identificador de grupo siempre
está en el bajo
32 bits como se muestra en el siguiente:
| 8 | 4 | 4 | 80 bits | 32 bits |
+------ -+----+----+---------------------------+--- --------------+
| 11111111 | FLGS | SCOP | reservados debe ser cero | ID de grupo |
+--------+----+----+---------------------------+-- ---------------+
Si bien esto limita el número de grupos de multidifusión permanente
para IPv6
2 ^ 32 es poco probable que una limitación en el futuro. Si
se hace necesario superar este límite en el futuro de multidifusión

33. todavía funcionan, pero el procesamiento será más lento vistoso.
Additional IPv6 multicast addresses are defined and registered by the
IANA [MASGN].
2.8 A Node's Required Addresses
A host is required to recognize the following addresses as
identifying itself:
o Its Link-Local Address for each interface
o Assigned Unicast Addresses
o Loopback Address
o All-Nodes Multicast Addresses
o Solicited-Node Multicast Address for each of its assigned
unicast and anycast addresses
o Multicast Addresses of all other groups to which the host
belongs.
A router is required to recognize all addresses that a host is
required to recognize, plus the following addresses as identifying
itself:
o The Subnet-Router anycast addresses for the interfaces it is
configured to act as a router on.
o All other Anycast addresses with which the router has been
configured.
o All-Routers Multicast Addresses
o Multicast Addresses of all other groups to which the router
belongs.

34. The only address prefixes which should be predefined in an
implementation are the:
o Unspecified Address
o Loopback Address
o Multicast Prefix (FF)
o Local-Use Prefixes (Link-Local and Site-Local)
o Pre-Defined Multicast Addresses
o IPv4-Compatible Prefixes
Implementations should assume all other addresses are unicast unless
specifically configured (eg, anycast addresses).
3. Security Considerations
IPv6 addressing documents do not have any direct impact on Internet
infrastructure security. Authentication of IPv6 packets is defined
in [AUTH].
APPENDIX A : Creating EUI-64 based Interface Identifiers
-------------------------------------------------- ------
Depending on the characteristics of a specific link or node there are
a number of approaches for creating EUI-64 based interface
identifiers. This appendix describes some of these approaches.
Links or Nodes with EUI-64 Identifiers
The only change needed to transform an EUI-64 identifier to an
interface identifier is to invert the "u" (universal/local) bit. Para
example, a globally unique EUI-64 identifier of the form:

35. |0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
donde "C" son los bits de la Company_id asignado, "0" es el valor de
of the universal/local bit to indicate global scope, "g" is
individual/group bit, and "m" are the bits of the manufacturer-
selected extension identifier. The IPv6 interface identifier would
be of the form:
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
The only change is inverting the value of the universal/local bit.
Links or Nodes with IEEE 802 48 bit MAC's
[EUI64] defines a method to create a EUI-64 identifier from an IEEE
48bit MAC identifier. This is to insert two octets, with hexadecimal
values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the
company_id and vendor supplied id). For example the 48 bit MAC with
global scope:
|0 1|1 3|3 4|
|0 5|6 1|2 7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|

36. +----------------+----------------+----------------+
donde "C" son los bits de la Company_id asignado, "0" es el valor de
of the universal/local bit to indicate global scope, "g" is
individual/group bit, and "m" are the bits of the manufacturer-
selected extension identifier. The interface identifier would be of
the form:
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
When IEEE 802 48bit MAC addresses are available (on an interface or a
node), an implementation should use them to create interface
identifiers due to their availability and uniqueness properties.
Links with Non-Global Identifiers
There are a number of types of links that, while multi-access, do not
have globally unique link identifiers. Examples include LocalTalk
and Arcnet. The method to create an EUI-64 formatted identifier is
to take the link identifier (eg, the LocalTalk 8 bit node
identifier) and zero fill it to the left. For example a LocalTalk 8
bit node identifier of hexadecimal value 0x4F results in the
following interface identifier:
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|0000000000000000|0000000000000000|0000000000000000|0000000001001111|

37. +----------------+----------------+----------------+----------------+
Note that this results in the universal/local bit set to "0" to
indicate local scope.
Links without Identifiers
There are a number of links that do not have any type of built-in
identificador. The most common of these are serial links and
configured
tunnels. Interface identifiers must be chosen that are unique for
the link.
When no built-in identifier is available on a link the preferred
approach is to use a global interface identifier from another
interface or one which is assigned to the node itself. To use this
approach no other interface connecting the same node to the same link
may use the same identifier.
If there is no global interface identifier available for use on the
link the implementation needs to create a local scope interface
identificador. The only requirement is that it be unique on the link.
There are many possible approaches to select a link-unique interface
identificador. Estos incluyen:
Manual Configuration
Generated Random Number
Node Serial Number (or other node-specific token)
The link-unique interface identifier should be generated in a manner
that it does not change after a reboot of a node or if interfaces are
added or deleted from the node.

38. The selection of the appropriate algorithm is link and implementation
dependent. The details on forming interface identifiers are defined
in the appropriate "IPv6 over <link>" specification. It is strongly
recommended that a collision detection algorithm be implemented as
part of any automatic algorithm.
APPENDIX B: ABNF Description of Text Representations
-------------------------------------------------- --
This appendix defines the text representation of IPv6 addresses and
prefixes in Augmented BNF [ABNF] for reference purposes.
IPv6address = hexpart [ ":" IPv4address ]
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6prefix = hexpart "/" 1*2DIGIT
hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
APPENDIX C: CHANGES FROM RFC-1884
---------------------------------
The following changes were made from RFC-1884 "IP Version 6
Addressing Architecture":
- Added an appendix providing a ABNF description of text
representations.
- Clarification that link unique identifiers not change after
reboot or other interface reconfigurations.

39. - Clarification of Address Model based on comments.
- Changed aggregation format terminology to be consistent with
aggregation draft.
- Added text to allow interface identifier to be used on more than
one interface on same node.
- Added rules for defining new multicast addresses.
- Added appendix describing procedures for creating EUI-64 based
interface ID's.
- Added notation for defining IPv6 prefixes.
- Changed solicited node multicast definition to use a longer
prefix.
- Added site scope all routers multicast address.
- Defined Aggregatable Global Unicast Addresses to use "001" Format
Prefix.
- Changed "010" (Provider-Based Unicast) and "100" (Reserved for
Geographic) Format Prefixes to Unassigned.
- Added section on Interface ID definition for unicast addresses.
Requires use of EUI-64 in range of format prefixes and rules for
setting global/local scope bit in EUI-64.
- Updated NSAP text to reflect working in RFC1888 .
- Removed protocol specific IPv6 multicast addresses (eg, DHCP)
y hace referencia a las definiciones IANA.
- Removed section "Unicast Address Example". Had become OBE.
- Added new and updated references.
- Minor text clarifications and improvements.
REFERENCIAS
[ABNF] Crocker, D., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234 , November 1997.
[AGGR] Hinden, R., O'Dell, M., and S. Deering, "An

40. Aggregatable Global Unicast Address Format", RFC 2374 , July
1998.
[AUTH] Atkinson, R., "IP Authentication Header", RFC 1826 , August
1995.
[ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546 , November 1993.
[CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): An Address Assignment and
Aggregation Strategy", RFC 1519 , September 1993.
[ETHER] Crawford, M., "Transmission of IPv6 Pacekts over Ethernet
Networks", Work in Progress.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/db/oui/tutorials/EUI64.html ,
Marzo de 1997.
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", Work in Progress.
[IPV6] Deering, S., and R. Hinden, Editors, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 1883 , December 1995.
[MASGN] Hinden, R., and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375 , July 1998.
[NSAP] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888 , August 1996.

41. [ RFC2119 ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119 , March 1997.
[TOKEN] Thomas, S., "Transmission of IPv6 Packets over Token Ring
Networks", Work in Progress.
[TRAN] Gilligan, R., and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1993 , April 1996.
AUTHORS' ADDRESSES
Robert M. Hinden
Nokia
232 Java Drive
Sunnyvale, CA 94089
EE.UU.
Phone: +1 408 990-2004
Fax: +1 408 743-5677
EMail: hinden@iprg.nokia.com
Stephen E. Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
EE.UU.
Phone: +1 408 527-8213
Fax: +1 408 527-8254
EMail: deering@cisco.com

42. Declaración Copyright completa
Copyright (C) The Internet Society (1998). Todos los derechos
reservados.
Este documento y sus traducciones pueden ser copiados y facilitados a
otros, y las obras derivadas que comentar o lo explican
o ayudar en su implementación pueden ser copiados, publicados
y distribuyó, en todo o en parte, sin restricción de ningún
especie, siempre que el aviso de copyright anterior y este párrafo
son
incluido en todas esas copias y trabajos derivados. Sin embargo,
este
documento en sí no puede ser modificado de ninguna manera, como
mediante la eliminación de
el aviso de copyright o referencias a la Sociedad de Internet o de
otros
Organizaciones de Internet, excepto cuando sea necesario con el fin
de
el desarrollo de estándares de Internet, en cuyo caso los
procedimientos para los
los derechos de autor se define en el proceso de normalización de
Internet debe ser
seguido, o según sea necesario traducirla a otros idiomas distintos
Inglés.
Los limitados permisos concedidos anteriormente son perpetuos y no se
revocados por la Internet Society ni sus sucesores o cesionarios.
Este documento y la información contenida en este documento se
proporciona en un
"TAL CUAL" y LA INTERNET SOCIETY Y LA INTERNET ENGINEERING

43. GRUPO DE TRABAJO RENUNCIA A TODA GARANTÍA, EXPRESA O IMPLÍCITA,
INCLUYENDO
PERO NO LIMITADO A CUALQUIER GARANTÍA DE QUE EL USO DE LA INFORMACIÓN
Aquí no vulnere cualquier derecho o cualquier garantía implícita de
COMERCIABILIDAD O IDONEIDAD PARA UN PROPÓSITO PARTICULAR.