Your SlideShare is downloading. ×
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Rfc2373
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rfc2373

495

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
495
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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.

×