tutorial de ipv6

5/20/2018 Tutorial de IPv6

1/46

- 1 -

Tutorial de IPv6

1. Los mot ivos de IPv6

El motivo bsico por el que surge, en el seno del IETF (Internet EngineeringTask Force), la necesidad de crear un nuevo protocolo, que en un primer momen-to se denomin IPng (Internet Protocol Next Generation, o Siguiente Generacindel Protocolo Internet), fue la evidencia de la falta de direcciones.

IPv4 tiene un espacio de direcciones de 32 bits, es decir, 232

(4.294.967.296).En cambio, IPv6 nos ofrece un espacio de 2128

(340.282.366.920.938.463.463.374.607.431.768.211.456).

Sin embargo, IPv4 tiene otros problemas o dificultades que IPv6 solucionao mejora.

Los creadores de IPv4, a principio de los aos 70, no predijeron en ningnmomento, el gran xito que este protocolo iba a tener en muy poco tiempo, en unagran multitud de campos, no slo cientficos y de educacin, sino tambin en in-

numerables facetas de la vida cotidiana.Podemos recordar algunas famosas frases que nos ayudarn a entender

hasta que punto, los propios precursores de la revolucin tecnolgica que esta-mos viviendo, no llegaron a prever:

Pienso que el mercado mundial de ordenadores puede ser de cincounidades, Thomas Watson, Presidente de IBM en 1.943

640 Kbps. de memoria han de ser suficientes para cualquier usuario,Bill Gates, Presidente de Microsoft, 1.981

32 bits proporcionan un espacio de direccionamiento suficiente paraInternet, Dr. Vinton Cerf, padre de Internet, 1.977

No es que estuvieran equivocados, sino que las Tecnologas de la Informa-cin han evolucionado de un modo mucho ms explosivo de lo esperado. Ade-ms, no dice el dicho es de sabios rectificar?

Desde ese momento, y debido a la multitud de nuevas aplicaciones en lasque IPv4 ha sido utilizado, ha sido necesario crear aadidos al protocolo bsico.Entre los parches ms conocidos, podemos citar medidas para permitir la Cali-dad de Servicio (QoS), Seguridad (IPsec), y Movilidad, fundamentalmente.

El inconveniente ms importante de estas ampliaciones de IPv4, es que uti-lizar cualquiera de ellos es muy fcil, pero no tanto cuando pretendemos usar almismo tiempo dos aadidos, y no digamos que se convierte en casi imposible o


2/46

- 2 -

muy poco prctico el uso simultneo de tres o ms, llegando a ser un autnticomalabarismo de circo.

2. Porqu IPv6?

Como deca en prrafos anteriores, la ventaja fundamental de IPv6 es elespacio de direcciones.

El reducido espacio de IPv4, a pesar de disponer de cuatro mil millones dedirecciones (4.294.967.296), junto al hecho de una importante falta de coordina-cin, durante la dcada de los 80, en la delegacin de direcciones, sin ningn tipode optimizacin, dejando incluso grandes espacios discontinuos, nos esta llevan-do a lmites no sospechados en aquel momento.

Por supuesto, hay una solucin que podramos considerar como evidente,como sera la renumeracin, y reasignacin de dicho espacio de direccionamien-

to. Sin embargo, no es tan sencillo, es incluso impensable en algunas redes, yaque requiere unos esfuerzos de coordinacin, a escala mundial, absolutamenteimpensables.

Adems, uno de los problemas de IPv4 permanecera: la gran dimensinde las tablas de encaminado (routing) en el troncal de Internet, que la hace inefi-caz, y perjudica enormemente los tiempos de respuesta.

La falta de direcciones no es apreciable por igual en todos los puntos de lared, de hecho, no es casi apreciable, por el momento, en Norte Amrica. Sin em-bargo, en zonas geogrficas como Asia (en Japn la situacin esta llegando a ser

crtica), y Europa, el problema se agrava.

Como ejemplos, podemos citar el caso de China que ha pedido direccionespara conectar 60.000 escuelas, tan slo ha obtenido una clase B (65.535 direc-ciones), o el de muchos pases Europeos, Asiticos y Africanos, que solo tienenuna clase C (255 direcciones) para todo el pas.

Tanto en Japn como en Europa el problema es creciente, dado al impor-tante desarrollo de las redes de telefona celular, inalmbricas, mdems de cable,xDSL, etc., que requieren direcciones IP fijas para aprovechar al mximo sus po-sibilidades e incrementar el nmero de aplicaciones en las que pueden ser em-

pleados.

La razn de utilizacin de las direcciones IP por parte de los usuarios, estapasando en pocos meses de 10:1 a 1:1, y la tendencia se invertir. En pocos me-ses, podemos ver dispositivos siempre conectados, con lo que fcilmente unusuario podra tener, en un futuro no muy lejano, hasta 50 o 100 IPs (1:50 o1:100).

Algunos Proveedores de Servicios Internet se ven incluso obligados a pro-porcionar a sus clientes direcciones IP privadas, mediante mecanismos de NAT(traslacin de direcciones, es decir, usar una sola IP pblica para toda una red

privada). De hecho, casi todos los PSIs se ven obligados a delegar tan slo redu-cidos nmeros de direcciones IP pblicas para sus grandes clientes corporativos.


3/46

- 3 -

Como ya he apuntado, la solucin, temporalmente, es el uso de mecanis-mos NAT. Desafortunadamente, de seguir con IPv4, esta tendencia no seratemporal, sino invariablemente permanente. Ello implica la imposibilidad prcti-ca de muchas aplicaciones, que quedan relegadas a su uso en Intranets, dadoque muchos protocolos son incapaces de atravesar los dispositivos NAT:

RTP y RTCP (Real-time Transport Protocol y Real Time Control Proto-col) usan UDP con asignacin dinmica de puertos (NAT no soporta estatraslacin).

La autenticacin Kerberos necesita la direccin fuente, que es modificadapor NAT en la cabecera IP.

IPsec pierde integridad, debido a que NAT cambia la direccin en la cabe-cera IP.

Multicast, aunque es posible, tcnicamente, su configuracin es tan com-plicada con NAT, que en la prctica no se emplea.

3. Cifras: el crecimiento de Internet

Las cifras de internautas, esperadas en los prximos aos, avalan lo ex-puesto:

Africa: 800.000.000 (slo 3.000.000 sin NAT)

Amrica Central y del Sur: 500.000.000 (slo 10.000.000 sin NAT)

Amrica del Norte: 500.000.000 (slo 125.000.000 sin NAT)

Asia: 2.500.000.000 (slo 50.000.000 sin NAT)

Europa Occidental: 250.000.000 (slo 50.000.000 sin NAT)

Pero lo ms importante es el imparable crecimiento de aplicaciones quenecesitan direcciones IP pblicas nicas, globales, vlidas para conexiones ex-tremo a extremo, y por tanto encaminables (enrutables): Videoconferencia, Vozsobre IP, seguridad, e incluso juegos.

Veamos ms cifras. Slo en Estados Unidos de Amrica, el mercado po-tencial de aplicaciones susceptibles de ser conectadas a la red, segn Driscol &Associates, en un estudio del ao 1.995, era:

MERCADO VERTICAL EJEMPLOS DEAPLICACIN TAMAO DELMERCADO

Lectura de Contadores Lectura de consumos de agua, gas, electricidad,etc.

242.000.000

Seguridad Sistemas de alarma, incendios, etc., tanto residen-ciales como comerciales

24.000.000

Posicionamiento de Veh-culos/flotas e informacinde condiciones

Seguimiento automtico de vehculosSeguimiento de inventariosDiagnstico y seguridad de vehculos

15.000.000

Monitorizacin Mquinas de venta automtica (vending)Buzones de correoGas e irrigacin

7.900.000

Total 288.900.000

En 1.997, el mercado de dispositivos con aplicaciones capaces de conec-tarse a Internet (sin incluir terminales ni ordenadores, tan slo WebTV, agendas

electrnicas, telfonos con acceso a Internet, y consolas de juegos), era de3.000.000. En el ao 1.998, este se duplica hasta llegar a los 6.000.000, y lasprevisiones de crecimiento para el 2.002, segn IDC, son de 56.000.000.


4/46

- 4 -

Slo contabilizando el crecimiento de la nueva generacin de telefona m-vil (UMTS), en el ao 2.003 se prevn cifras del orden de los 1.000.000.000 deusuarios, la misma cifra que para la telefona fija y que para el nmero de usua-rios fijos de Internet. En ese momento, los usuarios mviles con conexin a In-ternet se acercarn a los 400.000.000.

El mismo Foro UMTS/GSM prev unas necesidades de direcciones IP paralos dispositivos de la red (no para los dispositivos de los usuarios), para el ao2.005, de 3,2 millones, y de 6,3 para el 2.010. Segn el mismo informe, en el2.005, se requeriran un total de 20.000.000.000 de direcciones IP para los dispo-sitivos de los usuarios.

A esto hemos de sumar los innumerables dispositivos que vamos creando,o los ya existentes a los que damos nuevas o mejoradas aplicaciones, mediantesu conexin a la red, valgan como ejemplos:

Telfonos, pues la siguiente generacin, sin duda, pasara por tecnologas

IP (VoIP). Televisin y Radio, tambin basados en tecnologas IP.

Sistemas de seguridad, televigilancia y control.

Frigorficos que evalan nuestros hbitos de consumo y nos dan la op-cin de a) imprimir la lista de la compra, b) hacer el pedido en el super-mercado para que nos sea entregado automticamente, c) hacer el pedi-do para que pasemos a recogerlo decidiendo in situ el resto de la com-pra, d) navegar por un supermercado virtual y permitirnos llenar el carrosegn nuestros hbitos aadiendo nuestros caprichos ocasionales.

Despertadores, que conocen nuestros tiempos de desplazamiento habi-tuales a nuestro lugar de trabajo, y con motivo de un accidente o grannevada, de los que son informados mediante los servicios de la red, cal-culan el tiempo adicional que necesitamos y nos levantan con la anticipa-cin precisa, an a riesgo de que los destrocemos al arrojarlos contra lapared!

Walkman MP3, que conectados a la red, nos permiten recuperar y alma-cenar creaciones musicales.

Nuevas tecnologas emergentes, como Bluetooth, WAP, redes inalmbri-cas, redes domsticas, etc., hacen ms patente esta necesidad de crecimiento, al

menos, en los que al nmero de direcciones se refiere.

Por ejemplo, la ltima tendencia es la de permitir a cualquier dispositivo se-rie, ser conectado a una LAN o WAN, y por que no a Internet. Este tipo de con-vertidores, denominados Universal Device Server, o Servidor de DispositivosUniversal, permite que aplicaciones impensables por las limitaciones de los ca-bleados serie, se realicen remotamente a travs de redes, o incluso que un siste-ma de alarmas, que antes requera un mdem dedicado para la conexin con lacentral de recepcin de alarmas, pueda ahora enviar un e-mail, con todo lujo dedetalles!.

Podramos hablar, en general, de casi cualquier dispositivo tanto domsticocomo industrial, integrado en la gran red, pero tambin en dispositivos de controlmdico, marcapasos, etc.


5/46

- 5 -

4. Conclusin

Me permito reflejar aqu una conclusin de una importante compaa de in-geniera y consultora Canadiense, Viagnie, tambin miembro del Foro IPv6,que copreside el directorado tcnico:

La verdadera cuestin no es si necesitamos y creemos en IPv6, sino es-tamos interesados en una red que permita a cualquier dispositivo electrnico IPcomunicarse transparentemente con otros, independientemente de su localiza-cin, en LA red global?

Mi propia conclusin, extendiendo la frase anterior, a la que me adhiero ca-tegricamente, es:

El camino de IPv4 a IPv6 no es una cuestin de transicin ni de migracin,sino de evolucin, de integracin, pero se trata de una evolucin disruptora, rom-

pedora, y al mismo tiempo necesaria. IPv6 nos permitir un crecimiento escalabley simple, principales handicaps actuales de IPv4. Preparemos y mejoremos nues-tras redes, las de nuestros clientes, las de nueva implantacin, con dispositivos,sistemas operativos y aplicaciones que estn realmente listos o en camino decumplir las especificaciones de IPv6, sin por ello dejar de ser vlidos en IPv4. Hayque asegurar el futuro, no hipotecarlo, frente al inevitable comercio electrnicomvil (m-commerce), por la salud de la red global. Seamos y estemos IPv6READY!

5. Caractersticas principales de IPv6

Si resumimos las caractersticas fundamentales de IPv6 obtenemos la si-guiente relacin:

! Mayor espacio de direcciones.

! Plug & Play: Autoconfiguracin.

! Seguridad intrnseca en el ncleo del protocolo (IPsec).

! Calidad de Servicio (QoS) y Clase de Servicio (CoS).

! Multicast: Envo de UN mismo paquete a un grupo de receptores.

! Anycast: Envo de UN paquete a UN receptor dentro de UN grupo.

! Paquetes IP eficientes y extensibles, sin que haya fragmentacin en los

encaminadores (routers), alineados a 64 bits (preparados para su pro-cesado ptimo con los nuevos procesadores de 64 bits), y con una ca-becera de longitud fija, ms simple, que agiliza su procesado por partedel encaminador (router).

! Posibilidad de paquetes con carga til (datos) de ms de 65.535 bytes.

! Encaminado (enrutado) ms eficiente en el troncal (backbone) de la red,debido a una jerarqua de direccionamiento basada en la agregacin.

! Renumeracin y multi-homing, que facilita el cambio de proveedor deservicios.

! Caractersticas de movilidad.

Pero hay que insistir, de nuevo, en que estas son las caractersticas bsi-cas, y que la propia estructura del protocolo permite que este crezca, o dicho de


6/46

- 6 -

otro modo, sea escalado, segn las nuevas necesidades y aplicaciones o servi-cios lo vayan precisando.

Precisamente, la escalabilidad es la baza ms importante de IPv6 frente aIPv4.

6. Un poco de historia

Bsicamente ha habido tres fases importantes en el desarrollo de IPv4 has-ta lo que hoy conocemos como IPv6:

1.992 TUBA

Implementacin de mecanismos para usar TCP y UDP sobremayores direcciones.

Se emplea ISO CLNP (Connection-Less Network Protocol, pro-tocolo de redes sin conexin).

Se descarta.

1.993 SIPP

Proyecto Simple IP Plus.

Mezcla de SIP y PIP (dos tentativas anteriores para sustituirIPv4).

Direcciones de 64 bits.

1.994 IPng

Se adopta SIPP.

Se cambia el tamao de las direcciones a 128 bits. Se renombra como IPv6.

Como fase adicional, muy significativa, podemos aadir la constitucin ofi-cial, en Julio de 1.999, del IPv6 Forum o Foro IPv6, que ha implicado, en un pla-zo de tan solo seis meses, un importantsimo crecimiento respecto del fomento,promocin, uso y aplicacin del protocolo, con adopciones tan importantes comolas realizadas por la OTAN, ETSI, UMTS, 3GPP, o la Comunidad Europea.

Por ltimo, en el momento en que estas lneas estn siendo escritas, entreel 13 y el 16 de Marzo de 2.000, en Telluride (Colorado US), una pequea po-

blacin, antigua colonia minera fundada por Espaoles, convertida ahora en unimportante completo turstico dedicado al esqu, mientras se celebraba el 1erCon-greso Internacional de IPv6 en Norteamrica (Global IPv6 Summit), organizadopor el Foro IPv6, se ha producido un importante acontecimiento, de gran relevan-cia para IPv6.

La apertura del ciclo de conferencias ha incluido la presentacin magistralde Judy Estrin, CTO (Chief Technology Officer) y Vice-Presidente Senior de CiscoSystems, y miembro de las juntas directivas de importantes empresas como SunMicrosystems, Walt Disney y Federal Express. En su cargo es responsable de laplanificacin de tecnologas estratgicas y desarrollo del negocio, incluyendo in-

versiones y adquisiciones, ingeniera de consultora, proyectos avanzados de In-ternet, as como de asuntos legales y con el gobierno. Fue una de las personas


7/46

- 7 -

involucradas en los primeros desarrollos del protocolo TCP/IP, desde la Universi-dad de Stanford.

En su conferencia resalt frases tan significativas como Cisco esta com-prometido con IPv6, pero estamos comprometidos con la integracin, no con la

transicin, y urgi a la comunidad IPv6 a proporcionar herramientas y tcnicas degestin que faciliten la integracin de IPv6 con IPv4, indicando que debemos tra-er IPv6 junto a IPv4, como dos afluentes que convergen para crear un ro mspoderoso. Reconoci que Cisco ha percibido un creciente inters en IPv6, lo queles ha obligado, en los ltimos seis meses, a tomar alternativas al respecto, conimportantes esfuerzos de desarrollo al respecto.

Adems, cit las siguientes tendencias como conductoras de la necesidadde IPv6:

La creciente movilidad de los usuarios de Internet: los usuarios deseanpoder acceder a los mismos servicios Internet, tanto desde el trabajo,

como desde su casa, como desde el coche, lo que crea la necesidad dems de una IP por persona.

Redes domsticas: con la venida al hogar de accesos a Internet de granancho de banda, y oferta de servicios siempre conectado, los consu-midores desean conectar a la red dispositivos de seguridad, al igual queotros muchos.

La convergencia de voz, vdeo y datos, en infraestructuras basadas enIP: lo que implica el movimiento hacia la arquitectura ofrecida por IPv6,ms simple, escalable y ms fiable.

Judy Estrin remarc que la infraestructura actual de IPv4 est extendida, yque el mayor espacio de direcciones de IPv6 ofrece ventajas y eficacias, pero quelos mtodos de implementacin han de asegurar una integracin suave, entreIPv4 e IPv6.

Segn Judy, los desafos para la implantacin de IPv6 no son tcnicos, si-no de educacin de los usuarios finales, y del desarrollo de casos de negocio parala tecnologa. No debemos ilusionarnos slo por una nica aplicacin definitiva.

Pocas horas despus, dos relevantes proveedores de la industria de lasTecnologas de la Informacin, Cisco y Microsoft, han anunciado sus planes in-

mediatos de soportar oficialmente IPv6. Se puede encontrar ms informacin alrespecto se hallan en:http://www.networkworld.com/news/2000/0314ciscoipv6.html yhttp://www.microsoft.com/presspass/press/2000/Mar00/IPv6PR.asp.

Se trata de los ltimo gigantes en confirmar su apoyo incondicional aIPv6, pues previamente, durante un evento similar, celebrado en Diciembre delpasado ao, en Berln, el resto de los fabricantes haban hecho similares anun-cios.

De hecho, incluso antes de dicho encuentro, todos los fabricantes tenan

versiones beta, para algunos de sus productos. En concreto, uno de ellos,Ericsson Telebit, dispone de productos comerciales con IPv6 desde hace variosaos, y diversas plataformas UNIX tambin ofrecen dicho soporte.


8/46

- 8 -

Por otro lado, Sun Microsystems, anunciaba tambin la disponibilidad ac-tual de la nueva versin de su Sistema Operativo Solaris 8, que YA incluye IPv6.Ms informacin en http://www.sun.com/solaris/ipv6.

Adems, Nokia y Cernet (red de educacin e investigacin China), anun-

cian la implantacin mediante encaminadores (routers) de Nokia, de una nueva eimportante red, dentro del programa Internet 6, basada en este protocolo. Lanoticia completa esta disponible enhttp://www.businesswire.com/webbox/bw.031300/200731676.htm.

Por si no fuera suficiente, NTT Multimedia Communications Laboratories(MCL), subsidiaria de NTT Communications, anuncia la creacin del primer nodoneutro de intercambio de trfico Internet basado en IPv6, en Norteamrica, dispo-nible en el mes de Abril prximo. Informacin completa disponible enhttp://www.businesswire.com/webbox/bw.031300/200730477.htm. En Berln, du-rante otra de las conferencias del Foro IPv6, NTT hizo un anuncio similar, para el

mbito Europeo, incluso con ofertas de conexin gratuita, a dicho servicio, duran-te el primer ao.

Se trata de un complejo e inesperado cmulo de noticias al respecto deIPv6 que hacen prever una avalancha de otras nuevas, de similar ndole, y queauguran un desarrollo mucho ms rpido de los inicialmente previsto para IPv6.

Se dispone de un resumen actualizado de las noticias ms relevantes res-pecto de IPv6 en http://www.ipv6forum.com/navbar/ipv6forum/pressroom.htm.

7. Los cimientos de IPv6

Los criterios que se han seguido a lo largo del desarrollo de IPv6 han sidofundamentales para obtener un protocolo sencillo y al mismo tiempo extremada-mente consistente y escalable.

Son de destacar, entre estos criterios, adems de todo lo dicho hasta elmomento (nmero de direcciones, seguridad, movilidad y autoconfiguracin) laespecial aptitud para ser soportado por plataformas existentes, y una evolucinque permite su uso concurrente con IPv4: No es necesario realizar un cambioinstantneo en una fecha X, sino que el cambio es transparente.

Estos criterios se han alcanzado en gran medida por la ortogonalidad ysimplificacin de la cabecera de longitud fija, lo que redunda en la eficacia de suencaminado (enrutado), tanto en pequeos encaminadores como en los msgrandes, con soportes de ancho de banda muy superiores a los 100 Gbytes conlos dispositivos actuales.

Los equipos actuales, a pesar de sus tremendas capacidades de procesa-miento de paquetes, no seran capaces de acometer la misma tarea, ni de ofrecersoluciones a todas las necesidades emergentes, con la estructura de la cabeceraIPv4, sin contar la imposibilidad de gestionar las tablas de encaminado de lostroncales, si siguen creciendo al ritmo actual.


9/46

- 9 -

8. Especif icaciones bsicas de IPv6 (RFC2460)

Veamos, en primer lugar, la descripcin de la cabecera de un paqueteIPv4:

bits: 4 8 16 20 32

Versin Cabecera TOS Longitud Total

Identificacin Indicador Desplazamiento de Fragmentacin

TTL Protocolo Checksum

Direccin Fuente de 32 bits

Direccin Destino de 32 bits

Opciones

Como vemos, la longitud mnima de la cabecera IPv4 es de 20 bytes (cadafila de la tabla supone 4 bytes). A ello hay que aadir las opciones, que dependende cada caso.

En la tabla anterior hemos usado abreviaturas, en aquellos casos en losque son comunes. En el resto, nuestra particular traduccin de la nomenclaturaoriginal anglosajona, cuya leyenda de equivalencias indicamos a continuacin:

Version Versin (4 bits) Header Cabecera (4 bits) TOS (Type Of Service) Tipo de Servicio (1 byte) Total Length Longitud Total (2 bytes) Identification Identificacin (2 bytes)

Flag Indicador (4 bits) Fragment Offset Desplazamiento de Fragmentacin (12 bits

1.5 bytes) TTL (Time To Live) Tiempo de Vida (1 byte) Protocol Protocolo (1 byte) Checksum Cdigo de Verificacin (2 bytes) 32 bit Source Address Direccin Fuente de 32 bits (4 bytes) 32 bit Destination Address Direccin Destino de 32 bits (4 by-

tes)

En la tabla anterior, hemos marcado, mediante el color de fondo, los cam-pos que van a desaparecer en IPv6, y los que son modificados, segn el siguienteesquema:

Campo Modificado

Campo que Desaparece

Hemos pasado de tener 12 campos, en IPv4, a tan solo 8 en IPv6.

El motivo fundamental por el que los campos son eliminados, es la innece-saria redundancia. En IPv4 estamos facilitando la misma informacin de varias

formas. Un caso muy evidente es el checksum o verificacin de la integridad de lacabecera: Otros mecanismos de encapsulado ya realizan esta funcin (IEEE 802MAC, framing PPP, capa de adaptacin ATM, etc.).


10/46

- 10 -

El caso del campo de Desplazamiento de Fragmentacin, es ligeramentediferente, dado que el mecanismo por el que se realiza la fragmentacin de lospaquetes es totalmente modificado en IPv6, lo que implica la total inutilidad deeste campo. En IPv6 los encaminadores no fragmentan los paquetes, sino que deser precisa, dicha fragmentacin/desfragmentacin se produce extremo a extre-

mo.

Algunos de los campos son renombrados:

Longitud total longitud de carga til (payload length), que en definiti-va, es la longitud de los propios datos, y puede ser de hasta 65.536 by-tes. Tiene una longitud de 16 bits (2 bytes).

Protocolo siguiente cabecera (next header), dado que en lugar deusar cabeceras de longitud variables se emplean sucesivas cabecerasencadenadas, de ah que desaparezca el campo de opciones. En mu-chos casos ni siquiera es procesado por los encaminadores, sino tan

slo extremo a extremo. Tiene una longitud de 8 bits (1 byte). Tiempo de vida lmite de saltos (Hop Limit). Tiene una longitud de 8

bits (1 byte).

Los nuevos campos son:

Clase de Trfico (Traffic Class), tambin denominado Prioridad (Priori-ty), o simplemente Clase (Class). Podra ser ms o menos equivalente aTOS en IPv4. Tiene una longitud de 8 bits (1 byte).

Etiqueta de Flujo (Flow Label), para permitir trficos con requisitos detiempo real. Tiene una longitud de 20 bits.

Estos dos campos, como se puede suponer, son los que nos permiten unade las caractersticas fundamentales e intrnsecas de IPv6: Calidad de Servicio(QoS), Clase de Servicio (CoS), y en definitiva un poderoso mecanismo de controlde flujo, de asignacin de prioridades diferenciadas segn los tipos de servicios.

Por tanto, en el caso de un paquete IPv6, la cabecera tendra el siguienteformato:

bits: 4 12 16 24 32

Versin Clase de Trfico Etiqueta de Flujo

Longi tud de la Carga Util Siguiente Cabecera Lmite de Saltos

Direccin

Fuente

De

128 bits

Direccin

Destino

De

128 bits

El campo de versin, que es igual a 6, lgicamente, tiene una longitud de 4bits.


11/46

- 11 -

La longitud de esta cabecera es de 40 bytes, el doble que en el caso deIPv4, pero con muchas ventajas, al haberse eliminado campos redundantes.

Adems, como ya hemos mencionado, la longitud fija de la cabecera, impli-ca una mayor facilidad para su procesado en routers y conmutadores, incluso

mediante hardware, lo que implica unas mayores prestaciones.A este fin coadyuva, como hemos indicado anteriormente, el hecho de que

los campos estn alineados a 64 bits, lo que permite que las nuevas generacionesde procesadores y microcontroladores, de 64 bits, puedan procesar mucho mseficazmente la cabecera IPv6.

El valor del campo siguiente cabecera, indica cual es la siguiente cabece-ra y as sucesivamente. Las sucesivas cabeceras, no son examinadas en cadanodo de la ruta, sino slo en el nodo o nodos destino finales. Hay una nica ex-cepcin a esta regla: cuando el valor de este campo es cero, lo que indica opcin

de examinado y proceso salto a salto (hop-by-hop). As tenemos, por citar algu-nos ejemplos, cabeceras con informacin de encaminado, fragmentacin, opcio-nes de destino, autenticacin, encriptacin, etc., que en cualquier caso, han deser procesadas en el orden riguroso en que aparecen en el paquete.

Sin entrar en ms detalles, vanse a continuacin los siguientes ejemplosgrficos del uso del concepto de las cabeceras de extensin (definidas por elcampo siguiente cabecera), mecanismo por el que cada cabecera es encade-nada a la siguiente y anterior (si existen):

El MTU (Unidad Mxima de Transmisin), debe de ser como mnimo, de1.280 bytes, aunque se recomiendan tamaos superiores a 1.500 bytes. Los no-dos descubren el valor MTU a travs de la inspeccin de la ruta. Se prev as una

optimizacin de los paquetes y del nmero de cabeceras, dado el continuo creci-miento de los anchos de banda disponibles, as como del incremento del propiotrfico.

Cabecera IPv6

Siguiente=TCP

Cabecera TCP DATOS

Cabecera IPv6

S.=Routing

C. Routing

S.=TCP

Cabecera TCP DATOS

Cabecera IPv6

S.=Seguridad

C. Seguridad

S.=Fragmentacin

C. Fragmentacin

S.=TCP

DATOSCabecera TCP


12/46

- 12 -

Dado que IPv6 no realiza verificacin de errores de la cabecera, en trficoUDP, se requiere el empleo del su propio mecanismo de checksum.

9. Direcciones y direccionamiento en IPv6 (RFC2373)

Ya hemos dicho que IPv6 nos aporta, como principio fundamental, un es-pacio de 2128 direcciones, lo que equivale a 3,40E38(340.282.366.920.938.463.463.374.607.431.768.211.456).

Hagamos una cuenta rpida, para hacernos a la idea de lo que esta cifraimpronunciable implica. Calculemos el nmero de direcciones IP que podramostener por metro cuadrado de la superficie terrestre: nada ms y nada menos que665.570.793.348.866.943.898.599!

Indudablemente, hay cabida para todos los dispositivos que podamos ima-ginar, no solo terrestres, sino interplanetarios. Aunque, por el momento, no pode-

mos asegurar que tenga capacidad para los dispositivos intergalcticos.

9.1. Definicin de direccin en IPv6

Las direcciones IPv6 son identificadores de 128 bits para interfaces y con-juntos de interfaces. Dichas direcciones se clasifican en tres tipos:

Unicast: Identificador para una nica interfaz. Un paquete enviado a unadireccin unicast es entregado slo a la interfaz identificada con dichadireccin. Es el equivalente a las direcciones IPv4 actuales.

Anycast: Identificador para un conjunto de interfaces (tpicamente per-

tenecen a diferentes nodos). Un paquete enviado a una direccin any-cast es entregado en una (cualquiera) de las interfaces identificadas condicha direccin (la ms prxima, de acuerdo a las medidas de distanciadel protocolo de encaminado). Nos permite crear, por ejemplo, mbitosde redundancia, de forma que varias mquinas puedan ocuparse delmismo trfico segn una secuencia determinada (por el routing), si laprimera cae.

Multicast: Identificador para un conjunto de interfaces (por lo generalpertenecientes a diferentes nodos). Un paquete enviado a una direccinmulticast es entregado a todas las interfaces identificadas por dicha di-reccin. La misin de este tipo de paquetes es evidente: aplicaciones deretransmisin mltiple (broadcast).

9.2. Diferencias con IPv4

Hay algunas diferencias importantes en el direccionamiento de IPv6 res-pecto de IPv4:

No hay direcciones broadcast (su funcin es sustituida por direcciones mul-ticast).

Los campos de las direcciones reciben nombres especficos; denominamosprefijo a la parte de la direccin hasta el nombre indicado (incluyndolo).

Dicho prefijo nos permite conocer donde esta conectada una determinadadireccin, es decir, su ruta de encaminado.


13/46

- 13 -

Cualquier campo puede contener slo ceros o slo unos, salvo que explci-tamente se indique lo contrario.

Las direcciones IPv6, indistintamente de su tipo (unicast, anycast o multi-cast), son asignadas a interfaces, no nodos. Dado que cada interfaz perte-nece a un nico nodo, cualquiera de las direcciones unicast de las interfa-

ces del nodo puede ser empleado para referirse a dicho nodo. Todas las interfaces han de tener, al menos, una direccin unicast link-local

(enlace local).

Una nica interfaz puede tener tambin varias direcciones IPv6 de cual-quier tipo (unicast, anycast o multicast) o mbito.

Una misma direccin o conjunto de direcciones unicast pueden ser asigna-dos a mltiples interfaces fsicas, siempre que la implementacin trate di-chas interfaces, desde el punto de vista de internet, como una nica, lo quepermite balanceo de carga entre mltiples dispositivos.

Al igual que en IPv4, se asocia un prefijo de subred con un enlace, y se

pueden asociar mltiples prefijos de subred a un mismo enlace.

9.3. Reservas de espacio de direccionamiento en IPv6

A diferencia de las asignaciones de espacio de direccionamiento que se hi-cieron en IPv4, en IPv6, se ha reservado, que no asignado, algo ms del 15%,tanto para permitir una fcil transicin (caso del protocolo IPX), como para meca-nismos requeridos por el propio protocolo.

Estado Prefijo

(en binario)

Fraccin delEspacio

Reservado 0000 0000 1/256No Asignado 0000 0001 1/256

Reservado para NSAP 0000 001 1/128

Reservado para IPX 0000 010 1/128

No Asignado 0000 011 1/128

No Asignado 0000 1 1/32

No Asignado 0001 1/16

Direcciones Unicast Globales Agregables 001 1/8

No Asignado 010 1/8

No Asignado 011 1/8

No Asignado 100 1/8

No Asignado 101 1/8

No Asignado 110 1/8

No Asignado 1110 1/16No Asignado 1111 0 1/32

No Asignado 1111 10 1/64

No Asignado 1111 110 1/128

No Asignado 1111 1110 0 1/512

Direcciones Unicast Locales de Enlace 1111 1110 10 1/1.024

Direcciones Unicast Locales de Sitio 1111 1110 11 1/1.024

Direcciones Multicast 1111 1111 1/256

De esta forma se permite la asignacin directa de direcciones de agrega-cin, direcciones locales, y direcciones multicast, con reservas para OSI NSAP eIPX. El 85% restantes queda reservado para uso futuro.

Podemos distinguir las direcciones multicast de las unicast por el valor delocteto de mayor orden de la direccin (FF, o 11111111 en binario, indica multi-


14/46

- 14 -

cast). En cambio, en el caso de las anycast, no hay ninguna diferencia, sintcti-camente hablando, y por tanto, son tomadas del espacio de direcciones unicast.

9.4. Direcciones especiales en IPv6

Se han definido tambin las direcciones para usos especiales como: Direccin de auto-retorno o Loopback (::1) No ha de ser asig-

nada a una interfaz fsica; se trata de una interfaz virtual, puesse trata de paquetes que no salen de la mquina que los emite;nos permite hacer un bucle para verificar la correcta inicializacindel protocolo (dentro de una determinada mquina).

Direccin no especificada (::) Nunca debe ser asignada a nin-gn nodo, ya que se emplea para indicar la ausencia de direc-cin; por ejemplo, cuando se halla en el campo de direccin fuen-te, indica que se trata de un host que esta inicindose, antes de

que haya aprendido su propia direccin. Tneles dinmicos/automticos de IPv6 sobre IPv4 (::) Se denominan direcciones IPv6 compatibles con IPv4, ypermiten la retransmisin de trfico IPv6 sobre infraestructurasIPv4, de forma transparente.

80 bits 16 bits 32 bits

0000 ... 0000 0000 direccin IPv4

Representacin automtica de direcciones IPv4 sobre IPv6(::FFFF:) permite que los nodos que slo so-portan IPv4, puedan seguir trabajando en redes IPv6. Se deno-

minan direcciones IPv6 mapeadas desde IPv4.80 bits 16 bits 32 bits

0000 ... 0000 FFFF Direccin IPv4

9.5. Representacin de las direcciones IPv6

La representacin de las direcciones IPv6 sigue el siguiente esquema:

a) x:x:x:x:x:x:x:x, donde x es un valor hexadecimal de 16 bits, de la por-cin correspondiente a la direccin IPv6. No es preciso escribir los ce-ros a la izquierda de cada campo. Ejemplos:

FEDC:BA98:7654:3210:FEDC:BA98:7654:32101080:0:0:0:8:800:200C:417A

b) Dado que, por el direccionamiento que se ha definido, podrn existirlargas cadenas de bits cero, se permite la escritura de su abreviacin,mediante el uso de ::, que representa mltiples grupos consecutivosde 16 bits cero. Este smbolo slo puede aparecer una vez en la direc-cin IPv6. Ejemplos:Las direcciones:

1080:0:0:0:8:800:200C:417A (una direccin unicast)

FF01:0:0:0:0:0:0:101 (una direccin multicast)0:0:0:0:0:0:0:1 (la direccin loopback)0:0:0:0:0:0:0:0 (una direccin no especificada)

Pueden representarse como:


15/46

- 15 -

1080::8:800:200C:417A (una direccin unicast)FF01::101 (una direccin multicast)::1 (la direccin loopback):: (una direccin no especificada)

c) Una forma alternativa y muy conveniente, cuando nos hallemos en unentorno mixto IPv4 e IPv6, es x:x:x:x:x:x:d:d:d:d, donde x representavalores hexadecimales de 16 bits (6 porciones de mayor peso), y d re-presenta valores decimales de las 4 porciones de 8 bits de menor peso(representacin estndar IPv4). Ejemplos:

0:0:0:0:0:0:13.1.68.30:0:0:0:0:FFFF:129.144.52.38

Pueden representarse como:::13.1.68.3::FFFF:129.144.52.38

La representacin de los prefijos IPv6 se realiza del siguiente modo:

direccin-IPv6/longitud-del-prefijo

donde:

- direccin-IPv6 = una direccin IPv6 en cualquiera de las notaciones v-lidas

- longitud-del-prefijo = valor decimal indicando cuantos bits contiguos dela parte izquierda de la direccin componen el prefijo

Por ejemplo, las representaciones vlidas del prefijo de 60 bits12AB00000000CD3, son:

12AB:0000:0000:CD30:0000:0000:0000:0000/6012AB::CD30:0:0:0:0/6012AB:0:0:CD30::/60

Por tanto, para escribir una direccin completa, indicando la subred, po-dramos hacerlo como:

12AB:0:0:CD30:123:4567:89AB:CDEF/60

9.6. Direcciones unicast locales

Las direcciones unicast, son agregables con mscaras de bits contiguos,similares al caso de IPv4, con CIDR (Class-less Interdomain Routing). Comohemos visto, hay varias formas de asignacin de direcciones unicast, y otras pue-den ser definidas en el futuro.

Los nodos IPv6 pueden no tener ningn conocimiento o mnimo de la es-tructura interna de las direcciones IPv6, dependiendo de su misin en la red (porejemplo, host frente a router). Pero como mnimo, un nodo debe considerar que

las direcciones unicast (incluyendo la propia), no tienen estructura:


16/46

- 16 -

128 bits

Direccin del nodo

Un host algo ms sofisticado, conocera el prefijo de la subred del enlace alque esta conectado:

n bits 128-n bits

Prefijo de subred identificador de interfaz

Dispositivos ms sofisticados pueden tener un conocimiento ms amplio dela jerarqua de la red, sus lmites, etc., en ocasiones dependiendo de la posicinmisma que el dispositivo o host/router, ocupa en la propia red.

El identificador de interfaz se emplea, por tanto, para identificar interfacesen un enlace, y deben de ser nicos en dicho enlace. En muchos casos tambin

sern nicos en un mbito ms amplio. Por lo general, el identificador de interfazcoincidir con la direccin de la capa de enlace de dicha interfaz. El mismo identi-ficador de interfaz puede ser empleado en mltiples interfaces del mismo nodo,sin afectar a su exclusividad global en el mbito IPv6.

Se han definido dos tipos de direcciones unicast de uso local: Local de En-lace (Link-Local) y Local de Sitio (Site-Local).

Las direcciones locales de enlace han sido diseadas para direccionar unnico enlace para propsitos de auto-configuracin (mediante identificadores deinterfaz), descubrimiento del vecindario, o situaciones en las que no hay routers.

Por tanto, los encaminadores no pueden retransmitir ningn paquete con direc-ciones fuente o destino que sean locales de enlace (su mbito esta limitado a lared local). Tienen el siguiente formato:


1111111010 0 Identif icador de interfaz

Se trata de direcciones FE80::/10.

Las direcciones locales de sitio permiten direccionar dentro de un sitio lo-cal u organizacin, sin la necesidad de un prefijo global. Se configuran medianteun identificador de subred, de 16 bits. Los encaminadores no deben de retransmi-tir fuera del sitioningn paquete cuya direccin fuente o destino sea local de si-tio (su mbito esta limitado a la red local o de la organizacin).

10 bits 38 bits 16 bits 64 bits

1111111011 0 ID de subred Identificador de interfaz

Se trata de direcciones FEC0:::/10.

9.7. Direcciones anycast (RFC2526)

Tal y como hemos indicado antes, las direcciones anycast tienen el mismorango de direcciones que las unicast.


17/46

- 17 -

Cuando una direccin unicast es asignada a ms de una interfaz, convir-tindose en una direccin anycast, los nodos a los que dicha direccin ha sidoasignada, deben ser explcitamente configurados para que reconozcan que setrata de una direccin anycast.

Existe una direccin anycast, requerida para cada subred, que se denomi-na direccin anycast del router de la subred (subnet-router anycast address). Susintaxis es equivalente al prefijo que especifica el enlace correspondiente de ladireccin unicast, siendo el indicador de interfaz igual a cero:

n bits 128-n bits

Prefi jo de subred 00000000000000000000

Todos los routers han de soportar esta direccin para las subredes a lasque estn conectados. Los paquetes enviados a la direccin anycast del routerde la subred, sern enviados a un router de la subred.

Una aplicacin evidente de esta caracterstica, adems de la tolerancia afallos, es la movilidad. Imaginemos nodos que necesitan comunicarse con un rou-ter entre el conjunto de los disponibles en su subred.

Dentro de cada subred, los 128 valores superiores de identificadores de in-terfaz estn reservados para su asignacin como direcciones anycast de la sub-red.

La construccin de una direccin reservada de anycast de subred dependedel tipo de direcciones IPv6 usadas dentro de la subred.

Las direcciones cuyos tres primeros bits (prefijo de formato) tienen valoresentre 001 y 111 (excepto las de multicast, 1111 1111), indican con el bit univer-sal/local igual a cero, que el identificador de interfaz tiene 64 bits, y por tanto noes globalmente nico (es local). En este caso, las direcciones reservadas anycastde subred se construyen del siguiente modo:


Prefi jo de subred 1111110111 ... 111 ID anycast

Identificador de interfaz

En el resto de los casos, el identificador de interfaz puede tener una longi-tud diferente de 64 bits, por lo que la construccin se realiza segn el siguienteesquema:

n bits 121-n bits 7 bits

Prefi jo de subred 1111111 ... 1111111 ID anycast

Identificador de interfaz

9.8. Direcciones mult icast (RFC2375)

Una direccin multicast en IPv6, puede definirse como un identificador paraun grupo de nodos. Un nodo puede pertenecer a uno o varios grupos multicast.


18/46

- 18 -

Las direcciones multicast tienen el siguiente formato:

8 4 4 112 bi ts

11111111 000T mbito Identif icador de Grupo

El bit T indica, si su valor es cero, una direccin multicast permanente,asignada nicamente por la autoridad de numeracin global de Internet. En casocontrario, si su valor es uno, se trata de direcciones multicast temporales. Los 4bits que le preceden, que por el momento estn fijados a cero, estn reservadospara futuras actualizaciones.

Los bits mbito tienen los siguientes significados:

0 Reservado

1 Ambito Local de Nodo

2 Ambito Local de Enlace3 No asignado

4 No asignado

5 Ambito Local de Sitio

6 No asignado

7 No asignado

8 Ambito Local de Organizacin

9 No asignado

A No asignadoB No asignado

C No asignado

D No asignado

E Ambito Global

F Reservado

El Identificador de Grupo, identifica, como cabe esperar, el grupo de mul-ticast concreto al que nos referimos, bien sea permanente o temporal, dentro de

un determinado mbito.Por ejemplo, si asignamos una direccin multicast permanente, con el iden-

tificador de grupo 101 (hexadecimal), al grupo de los servidores de tiempo (NTS),entonces:

FF01::101 significa todos los NTS en el mismo nodo que el paquete origen

FF02::101 significa todos los NTS en el mismo enlace que el paquete ori-gen

FF05::101 significa todos los NTS en el mismo sitio que el paquete origen

FF0E::101 significa todos los NTS en Internet

Las direcciones multicast no-permanentes, slo tienen sentido en su propiombito. Por ejemplo, un grupo identificado por la direccin temporal multicast localde sitio FF15::101, no tiene ninguna relacin con un grupo usando la misma di-


19/46

- 19 -

reccin en otro sitio, ni con otro grupo temporal que use el mismo identificador degrupo (en otro mbito), ni con un grupo permanente con el mismo identificador degrupo.

Las direcciones multicast no deben ser usadas como direccin fuente en un

paquete IPv6, ni aparecer en ninguna cabecera de encaminado.Las principales direcciones multicast reservadas son las incluidas en el

rango FF0x:0:0:0:0:0:0:0.

Algunos ejemplos tiles de direcciones multicast, segn su mbito, seran:

FF01:0:0:0:0:0:0:1 todos los nodos (mbito local)

FF02:0:0:0:0:0:0:1 todos los nodos (mbito de enlace)

FF01:0:0:0:0:0:0:2 todos los routers (mbito local)

FF02:0:0:0:0:0:0:2 todos los routers (mbito de enlace)

FF05:0:0:0:0:0:0:2 todos los routers (mbito de sitio)

La direccin FF02:0:0:0:0:1:FFxx:xxxx, denominada Solicited-Node Ad-dress, o direccin de nodo solicitada, permite calcular la direccin multicast a par-tir de la unicast o anycast de un determinado nodo. Para ello, se sustituyen los 24bits de menor peso (x) por los mismos bits de la direccin original.

As, la direccin 4037::01:800:200E:8C6C se convertira enFF02::1:FF0E:8C6C.

Cada nodo debe de calcular y unirse a todas las direcciones multicast que

le corresponden para cada direccin unicast y anycast que tiene asignada.

9.9. Direcciones Requeridas para cualquier nodo

Todos los nodos, en el proceso de identificacin, al unirse a la red, debende reconocer como mnimo, las siguientes direcciones:

Sus direcciones locales de enlace para cada interfaz

Las direcciones unicast asignadas

La direccin de loopback

Las direcciones multicast de todos los nodos

Las direcciones multicast solicitadas para cada direccin unicast o any-cast asignadas

Las direcciones multicast de todos los grupos a los que dicho host perte-nece

Adems, en el caso de los routers, tienen que reconocer tambin:

La direccin anycast del router de la subnet, para las interfaces en lasque esta configurado para actuar como router

Todas las direcciones anycast con las que el router ha sido configurado

Las direcciones multicast de todos los routers Las direcciones multicast de todos los grupos a los que el router pertene-

ce


20/46

- 20 -

Adems, todos los dispositivos con IPv6, deben de tener, predefinidos, losprefijos siguientes:

Direccin no especificada

Direccin de loopback

Prefijo de multicast (FF) Prefijos de uso local (local de enlace y local de sitio)

Direcciones multicast predefinidas

Prefijos compatibles IPv4

Se debe de asumir que todas las dems direcciones son unicast a no serque sean especficamente configuradas (por ejemplo las direcciones anycast).

9.10. Direcciones unicast globales agregables (RFC2374)

Dado que uno de los problemas que IPv6 resuelve es la mejor organizacinjerrquica del routing en las redes pblicas (globales), es indispensable el concep-to de direccionamiento agregable.

En la actualidad ya se emplea este tipo de direcciones, basadas en laagregacin por parte de los proveedores del troncal Internet, y los mecanismosadoptados para IPv6, permiten su continuidad. Pero adems, se incorpora un me-canismo de agregacin basado en intercambios.

La combinacin de ambos es la que permite un encaminamiento muchoms eficiente, dando dos opciones de conectividad a unas u otras entidades de

agregacin.Se trata de una organizacin basada en tres niveles:

Topologa Pblica: conjunto de proveedores e intercambiadores queproporcionan servicios pblicos de trnsito Internet.

Topologa de Sitio: redes de organizaciones que no proporcionan servi-cios pblicos de trnsito a nodos fuera de su propio sitio.

Identificador de Interfaz: identifican interfaces de enlaces.

En la figura adjunta, el formato de direcciones agregables ha sido diseadopara soportar proveedores de larga distancia (identificados como Proveedor 1-4),

intercambiadores (Intercambiador 1 y 2), proveedores de niveles inferiores (podr-an ser ISPs, identificados como Proveedor 5 y 6), y Clientes (Cliente A-F).

A diferencia de lo que ocurre actualmente, los intercambiadores tambinproporcionarn direcciones pblicas IPv6. Las organizaciones conectadas a di-chos intercambiadores tambin recibirn servicios de conectividad directos, indi-rectamente a travs del intercambiador, de uno o varios proveedores de larga dis-tancia.


21/46

- 21 -

De esta forma, su direccionamiento es independiente de los proveedoresde trfico de larga distancia, y pueden, por tanto, cambiar de proveedor sin nece-sidad de renumerar su organizacin. Este es uno de los objetivos de IPv6.

Adems, una organizacin puede estar suscrita a mltiples proveedores(multi-homing o multi-localizacin), a travs de un intercambiador, sin necesidad

de tener prefijos de direcciones de cada uno de los proveedores.9.10.1. Estructura de direcciones unicast globales agregables

El formato de las direcciones unicast globales agregables es el siguiente:

3 13 8 24 16 64 bi ts

FP TLAID

Res. NLAID

SLAID

InterfazID

Topologa Pblica

Topologa de Sitio

Identificador de Interfaz

Donde:

FP Prefijo de Formato (001)- Format Prefix

TLA ID Identificador de Agregacin de Nivel Superior- Top-Level Aggregation Identifier

Res. Reservado para uso futuro

NLA ID Identificador de Agregacin de Siguiente Nivel- Next-Level Aggregation Identifier

SLA ID Identificador de Agregacin de Nivel de Sitio- Site-Level Aggregation Identifier

Interfaz ID Identificador de Interfaz

Proveedor

1

Intercambiador2

Proveedor

3

Cliente

A

Provee-dor

6

Cliente

C

Cliente

D

Cliente

E

Cliente

F

Cliente

B

Provee-dor

5

Proveedor2

Intercambiador1

Proveedor4


22/46

- 22 -

El campo Reservado permitir, en el futuro, ampliaciones organizadas delprotocolo, por ejemplo ampliar el nmero de bits de los campos TLA y NLA. Por elmomento contiene ceros.

9.10.2. Identificador de Agregacin de Nivel Superior

Se trata del nivel superior en la estructura jerrquica de enrutado.

Los routers situados en este nivel tienen, en la tabla de encaminado, unaentrada para cada TLA ID activo, y probablemente entradas adicionales relativasal propio TLA ID donde estn fsicamente situados.

Podran tener otras entradas, para su optimizacin, dependiendo de su to-pologa, pero siempre pensando en que se minimice la tabla.

Esta estructura de direccionamiento permite 8.192 (213) identificadores de

TLA. Se prev su crecimiento haciendo que este campo crezca hacia la derechaen el espacio reservado para el futuro, o usando este mismo formato/estructurapara prefijos de formato (FP) adicionales.

9.10.3. Identificador de Agregacin de Siguiente Nivel

Es empleado por organizaciones a las que se ha asignado un TLA, paracrear una estructura jerrquica de direccionamiento, acorde con su propia red, ypara identificar los sitios u organizaciones que de ella dependen.

Pueden reservar los bits superiores para la diferenciacin de la estructura

de su red, en funcin a sus propias necesidades.n 24-n bits 16 64 bits

NLA1 Site ID SLA ID Interfaz ID

Dado que cada organizacin que recibe un TLA dispone de 24 bits de es-pacio NLA, permite proporcionar servicio aproximadamente al nmero total dedirecciones IPv4 soportadas actualmente.

Las organizaciones que reciben un TLA pueden soportar varios NLA en supropio espacio de direccionamiento (Site ID). Esto permite que sirvan tanto a

clientes directos (suscriptores) como a otras organizaciones proveedoras de ser-vicios pblicos de trnsito. Y as sucesivamente, como se muestra en la siguientefigura:


23/46

- 23 -

n 24-n bits 16 64 bits


m 24-n-m bits 16 64 bits


o 24-n-m-o b its 16 64 b its


El diseo del espacio NLA de cada organizacin es libre para cada TLAasignado, y as sucesivamente con los niveles inferiores. Sin embargo, se reco-mienda seguir los procedimientos del RFC2050.

En cualquier caso es fundamental apreciar el balance entre eficacia de en-caminado agregable y flexibilidad. Las estructuras ms jerrquicas permiten una

mejor agregacin, y por tanto reducen las tablas de encaminado. Por el contrario,asignaciones ms planas del espacio NLA proporcionan mejor flexibilidad en laconexin (crecimientos no previstos en un determinado espacio), resultando entablas de encaminado mayores, y por tanto menos eficaces.

9.10.4. Identificador de Agregacin de Nivel de Sitio

El SLA es usado por organizaciones finales para crear su propia estructu-ra jerrquica de direcciones e identificar sus subredes. Es equivalente al conceptode subred en IPv4, con la muy apreciable diferencia de que cada corporacin tie-

ne un mayor nmero de subredes (16 bits proporcionan capacidad para 65.535).Del mismo modo que en el caso del NLA, se puede escoger entre una es-

tructura plana, o crear varios niveles, segn la figura adjunta:

n 16-n bits 64 bits

SLA1 Subred Interfaz ID

m 16-n-m bits 64 bits

SLA2 Subred Interfaz ID

Una gran compaa podra necesitar varios identificadores SLA. Como eslgico, cada caso depender de cmo estn conectadas sus diversas delegacio-nes.

9.11. Formato para la representacin en URLs (RFC2732)

Cuando navegamos, continuamente aludimos a URL, en muchas ocasio-nes sin conocer el significado precios de esta abreviatura.

La especificacin original (RFC2396), que data del ao 1.988, nos dice queUniform Resource Locator (Localizador de Recurso Uniforme), es un medio sim-

ple y extensible para identificar un recurso a travs de su localizacin en la red.Una vez aclarado esto, y de la misma forma que en ocasiones usamos di-

recciones en formato IPv4 para escribir un URL, se han descrito unas normas pa-


24/46

- 24 -

ra realizar la representacin literal de direcciones IPv6 cuando se usan herramien-tas de navegacin WWW.

El motivo por el que ha sido preciso realizar esta definicin es bien simple.Con la anterior especificacin no estaba permitido emplear el carcter : en una

direccin, sino como separador de puerto. Por tanto, si se desea facilitar opera-ciones tipo cortar y pegar (cut and paste), para trasladar direcciones entre dife-rentes aplicaciones, de forma rpida, era preciso buscar una solucin que evitasela edicin manual de las direcciones IPv6.

La solucin es bien sencilla: el empleo de los corchetes ([,]) para ence-rrar la direccin IPv6, dentro de la estructura habitual del URL.

Veamos algunos ejemplos; las direcciones siguientes:

FEDC:BA98:7654:3210:FEDC:BA98:7654:3210

1080:0:0:0:8:800:200C:4171

3ffe:2a00:100:7031::1

1080::8:800:200C:417A

::192.9.5.5

::FFFF:129.144.52.38

2010:836B:4179::836B:4179

Seran representadas como:

http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html

http://[1080:0:0:0:8:800:200C:417A]/index.html

http://[3ffe:2a00:100:7031::1]

http://[1080::8:800:200C:417A]/foo

http://[::192.9.5.5]/ipng

http://[::FFFF:129.144.52.38]:80/index.html

http://[2010:836B:4179::836B:4179]

Hemos aadido alguna complicacin, para que el propio lector descubrael uso del separador de puertos.

9.12. Resumiendo

Puede parecerle, al lector, un esquema muy complejo, pero en realidad esmuy simple y sobre todo, muy eficiente.

Los resultados de este esquema son:

a) Las direcciones siguen siendo asignadas por el proveedor, pero al cam-biar de proveedor, slo cambia el prefijo, y la red se renumera autom-ticamente (routers, sitios y nodos finales dispositivos servidores).


25/46

- 25 -

b) Las interfaces pueden tener mltiples direcciones.

c) Las direcciones tienen mbito (Global, Sitio, Enlace).

d) Las direcciones, al estar compuestas por un prefijo y un identificador deinterfaz, nos permiten separar quin es de donde esta conectado:

e) Adems, las direcciones tienen un perodo de vida (de validez).

El RFC2450 propone las reglas para la administracin de los TLAs yNLAs. Adems, en http://www.arin.net/regserv/ipv6/IPv6.txt, podemos encontrarms informacin al respecto de las normas para registros IPv6, del mismo modoque en http://www.ripe.net/ripencc/about/regional/maps/ipv6policy-draft-090699.html, o en http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html. Entodos los casos, la mxima autoridad competente es IANA (Internet AssignedNumbers Authority).

10. ICMPv6 (RFC2463)

El Protocolo de Mensajes de Control de Internet (Internet Control MessageProtocol), descrito originalmente en el documento RFC792 para IPv4, ha sido ac-tualizado para permitir su uso bajo IPv6.

El protocolo resultante de dicha modificacin es ICMPv6, y se le ha asigna-do un valor, para el campo de siguiente cabecera, igual a 58. ICMPv6 es parteintegral de IPv6 y debe ser totalmente incorporado a cualquier implementacin de

nodo IPv6.

ICMPv6 es empleado por IPv6 para reportar errores que se encuentran du-rante el procesado de los paquetes, as como para la realizacin de otras funcio-nes relativas a la capa Internet, como diagnsticos (ping).

El formato genrico de los mensajes ICMPv6 es el siguiente:

bits 8 16 32

Tipo Cdigo Checksum

Cuerpo del Mensaje

El campo tipo indica el tipo de mensaje, y su valor determina el formatodel resto de la cabecera.

Ambito Global

Ambito Sitio

Ambito Enlace


26/46

- 26 -

El campo cdigo depende del tipo de mensaje, y se emplea para crear unnivel adicional de jerarqua para la clasificacin del mensaje.

El checksum o cdigo de redundancia nos permite detectar errores en elmensaje ICMPv6.

Los mensajes ICMPv6 se agrupan en dos tipos o clases: mensaje de errory mensajes informativos. Los mensajes de error tienen cero en el bit de mayorpeso del campo tipo, por lo que sus valores se sitan entre 0 y 127.

Los valores de los mensajes informativos oscilan entre 128 y 255.

Los mensajes definidos por la especificacin bsica son los siguientes:

Mensajes de error ICMPv6

Tipo Descripcin y Cdigos

Destino no alcanzable (Destination Unreachable)Cdigo Descripcin

0 Sin ruta hacia el destino

1 Comunicacin prohibida administrativamente

2 Sin asignar

3 Direccin no alcanzable

1

4 Puerto no alcanzable

2 Paquete demasiado grande (Packet Too Big)

Tiempo excedido (Time Exceeded)Cdigo Descripcin

0 Lmite de saltos excedido

3

1 Tiempo de desfragmentacin excedido

Problema de parmetros (Parameter Problem)Cdigo Descripcin

0 Campo errneo en cabecera

1 Tipo de cabecera siguiente desconocida

4

2 Opcin IPv6 desconocida

Mensajes in formativos ICMPv6

Tipo Descripcin

128 Solicitud de eco (Echo Request)

129 Respuesta de eco (Echo Reply)

Se esta trabajando en nuevos tipos de mensajes, siendo el ms interesantede ellos el definido en un borrador de IETF (draft-ietf-ipngwg-icmp-name-lookups-05.txt), que permitir solicitar a un nodo informacin completa como su nombrede dominio completamente cualificado (Fully-Qualified-Domain-Name).

Por razones de seguridad, las cabeceras ICMPv6 pueden ser autenticadas

y encriptadas, usando la cabecera correspondiente. El uso de este mecanismopermite, adems, la prevencin de ataques ICMP, como el conocido Negacin deServicio (DoS o Denial of Service Attack).


27/46

- 27 -

11. Neighbor Discovery (RFC2461)

En IPv6, el protocolo equivalente, en cierto modo, a ARP en IPv4, es el quedenominamos descubrimiento del vecindario. Sin embargo, incorpora tambin lafuncionalidad de otros protocolos IPv4, como ICMP Router Discovery y ICMP

Redirect.

Tal como indica esta traduccin, consiste en el mecanismo por el cual unnodo que se incorpora a una red, descubre la presencia de otros, en su mismoenlace, para determinar sus direcciones en la capa de enlace, para localizar losrouters, y para mantener la informacin de conectividad (reachability) acerca delas rutas a los vecinos activos.

El protocolo ND (abreviatura comn de Neighbor Discovery), tambin seemplea para mantener limpios los caches donde se almacena la informacinrelativa al contexto de la red a la que esta conectado un nodo (host o router), y

por tanto para detectar cualquier cambio en la misma. Cuando un router, o unaruta hacia l, falla, el host buscar alternativas funcionales.

ND emplea los mensajes de ICMPv6, incluso a travs de mecanismos demulticast en la capa de enlace, para algunos de sus servicios.

El protocolo ND es bastante completo y sofisticado, ya que es la base parapermitir el mecanismo de autoconfiguracin en IPv6.

Define, entre otros, mecanismos para: descubrir routers, prefijos y parme-tros, autoconfiguracin de direcciones, resolucin de direcciones, determinacin

del siguiente salto, deteccin de nodos no alcanzables, deteccin de direccionesduplicadas o cambios, redireccin, balanceo de carga entrante, direcciones any-cast, y anunciacin de proxies.

ND define cinco tipos de paquetes ICMPv6:

Solicitud de Router (Router Solicitation) generado por una interfaz cuan-do es activada, para pedir a los routers que se anuncien inmediatamente.Tipo en paquete ICMPv6 = 133.

Anunciacin de Router (Router Advertisement) generado por los routersperidicamente (entre cada 4 y 1800 segundos) o como consecuencia deuna solicitud de router, a travs de multicast, para informar de su presen-cia as como de otros parmetros de enlace y de Internet, como prefijos(uno o varios), tiempos de vida, configuracin de direcciones, lmite de saltosugerido, etc. Es fundamental para permitir la renumeracin. Tipo en pa-quete ICMPv6 = 134.

Solicitud de Vecino (Neighbor Solicitation) generado por los nodos paradeterminar la direccin en la capa de enlace de sus vecinos, o para verifi-car que el nodo vecino sigue activo (es alcanzable), as como para detectarlas direcciones duplicadas. Tipo en paquete ICMPv6 = 135.

Anunciacin de Vecino (Neighbor Advertisement) generado por los nodoscomo respuesta a la solicitud de vecino, o bien para indicar cambios de

direcciones en la capa de enlace. Tipo en paquete ICMPv6 = 136.


28/46

- 28 -

Redireccin (Redirect) generado por los routers para informar a los hostde un salto mejor para llegar a un determinado destino. Equivalente, enparte a ICMP redirect. Tipo en paquete ICMPv6 = 137.

El protocolo ND, frente a los mecanismos existentes en IPv4, reporta nu-

merosas ventajas: El descubrimiento de routers es parte de la base del protocolo, no es

preciso recurrir a los protocolos de encaminado.

La anunciacin de router incluye las direcciones de la capa de enlace,no es necesario ningn intercambio adicional de paquetes para su reso-lucin.

La anunciacin de router incluye los prefijos para el enlace, por lo queno hay necesidad de un mecanismo adicional para configurar la msca-ra de red.

La anunciacin de router permite la autoconfiguracin de direcciones

Los routers pueden anunciar a los host del mismo enlace el MTU (ta-mao mximo de la unidad de transmisin).

Se extienden los multicast de resolucin de direcciones entre 232direc-ciones, reduciendo de forma importante las interrupciones relativas a laresolucin de direcciones en nodos distintos al objetivo, y evitando lasinterrupciones en nodos sin IPv6.

Las redirecciones contienen la direccin de la capa de enlace del nuevosalto, lo que evita la necesidad de una resolucin de direccin adicional.

Se pueden asignar mltiples prefijos al mismo enlace y por defecto loshost aprenden todos los prefijos por la anunciacin de router. Sin em-

bargo, los routers pueden ser configurados para omitir parte o todos losprefijos en la anunciacin, de forma que los host consideren que losdestinos estn fuera del enlace; de esta forma, enviarn el trfico a losrouters, quin a su vez lo redireccionar segn corresponda.

A diferencia de IPv4, en IPv6 el receptor de una redireccin asume queel siguiente salto esta en el mismo enlace. Se prev una gran utilidad enel sentido de no ser deseable o posible que los nodos conozcan todoslos prefijos de los destinos en el mismo enlace (enlaces sin multidifusiny media compartida).

La deteccin de vecinos no alcanzables es parte de la base de mejoras

para la robustez en la entrega de paquetes frente a fallos en routers,particiones de enlaces, nodos que cambian sus direcciones, nodos m-viles, etc.

A diferencia de ARP, en ND se puede detectar fallos de la mitad del en-lace, es decir, con conectividad en un slo sentido, evitando el trficohacia ellos.

A diferencia de IPv4, no son precisos campos de preferencia (para defi-nir la estabilidad de los routers). La deteccin de vecinos no alcanza-bles sustituir los caminos desde routers con fallos a otros activos.

El uso de direcciones de enlace local para identificar routers, permite a

los hosts que mantengan su asociacin con los mismos, en el caso deque se realice una renumeracin para usar nuevos prefijos globales.


29/46

- 29 -

El lmite de saltos es siempre igual a 255, lo que evita que haya envosaccidentales o intencionados desde nodos fuera del enlace, dado quelos routers decrementan automticamente este campo en cada salto.

Al realizar la resolucin de direcciones en la capa ICMP, se independizael protocolo del medio, permitiendo mecanismos de autenticacin y se-

guridad normalizados.

En este RFC se describe, adems, el modelo conceptual de las estructu-ras de datos y su manipulacin, que un dispositivo (host o router) requerira paracumplir los protocolos IPv6. Se trata, pues, de un documento clave para la correc-ta interpretacin de IPv6, cuando se trata de aplicarlo a su uso por parte de des-arrolladores.

En resumen, ND reemplaza, con grandes mejoras e importantes ventajas,a ARP.

12. Autoconfiguracin en IPv6 (RFC2462)

La autoconfiguracin es el conjunto de pasos por los cuales un host decidecomo autoconfigurar sus interfaces en IPv6. Este mecanismo es el que nos permi-te afirmar que IPv6 es Plug & Play.

El proceso incluye la creacin de una direccin de enlace local, verificacinde que no esta duplicada en dicho enlace y determinacin de la informacin queha de ser autoconfigurada (direcciones y otra informacin).

Las direcciones pueden obtenerse de forma totalmente manual, medianteDHCPv6 (stateful o configuracin predeterminada), o de forma automtica (state-less o descubrimiento automtico, sin intervencin).

Este protocolo define el proceso de generar una direccin de enlace local,direcciones globales y locales de sitio, mediante el procedimiento automtico (sta-teless). Tambin define el mecanismo para detectar direcciones duplicadas.

La autoconfiguracin stateless (sin intervencin), no requiere ningunaconfiguracin manual del host, configuracin mnima (o ninguna) de routers, y noprecisa servidores adicionales. Permite a un host generar su propia direccin me-diante una combinacin de informacin disponible localmente e informacin anun-ciada por los routers. Los routers anuncian los prefijos que identifican la subred (osubredes) asociadas con el enlace, mientras el host genera un identificador deinterfaz, que identifica de forma nica la interfaz en la subred. La direccin secompone por la combinacin de ambos campos. En ausencia de router, el hostslo puede generar la direccin de enlace local, aunque esto es suficiente parapermitir la comunicacin entre nodos conectados al mismo enlace.

En la autoconfiguracin stateful (predeterminada), el host obtiene la direc-cin de la interfaz y/o la informacin y parmetros de configuracin desde un ser-vidor. Los servidores mantienen una base de datos con las direcciones que han

sido asignadas a cada host.Ambos tipos de autoconfiguracin (stateless y stateful), se complementan.

Un host puede usar autoconfiguracin sin intervencin (stateless), para generar


30/46

- 30 -

su propia direccin, y obtener el resto de parmetros mediante autoconfiguracinpredeterminada (stateful).

El mecanismo de autoconfiguracin sin intervencin se emplea cuando noimporta la direccin exacta que se asigna a un host, sino tan slo asegurarse que

es nica y correctamente enrutable.El mecanismo de autoconfiguracin predeterminada, por el contrario, nos

asegura que cada host tiene una determinada direccin, asignada manualmente.

Cada direccin es cedida a una interfaz durante un tiempo predefinido (po-siblemente infinito). Las direcciones tienen asociado un tiempo de vida, que indi-can durante cuanto tiempo esta vinculada dicha direccin a una determinadainterfaz. Cuando el tiempo de vida expira, la vinculacin se invalida y la direccinpuede ser reasignada a otra interfaz en cualquier punto de Internet.

Para gestionar la expiracin de los vnculos, una direccin pasa a travs dedos fases diferentes mientras est asignada a una interfaz. Inicialmente, una di-reccin es preferred (preferida), lo que significa que su uso es arbitrario y no es-t restringido. Posteriormente, la direccin es deprecated (desaprobada), en an-ticipacin a que el vnculo con su interfaz actual va a ser anulado.

Mientras esta en estado desaprobado, su uso es desaconsejado, aunqueno prohibido. Cualquier nueva comunicacin (por ejemplo, una nueva conexinTCP), debe usar una direccin preferida, siempre que sea posible.

Una direccin desaprobada debera ser usada tan solo por aquellas apli-

caciones que ya la venan utilizando y a las que les es muy difcil cambiar a otradireccin sin interrupcin del servicio.

Para asegurarse de que todas las direcciones configuradas son nicas, enun determinado enlace, los nodos ejecutan un algoritmo de deteccin de direccio-nes duplicadas, antes de asignarlas a una interfaz. Este algoritmo es ejecutadopara todas las direcciones, independientemente de que hayan sido obtenidas me-diante autoconfiguracin stateless o stateful.

La autoconfiguracin esta diseada para hosts, no para routers, aunqueello no implica que parte de la configuracin de los routers tambin pueda ser rea-

lizada automticamente (generacin de direcciones de enlace local). Adems, losrouters tambin tienen que aprobar el algoritmo de deteccin de direcciones du-plicadas.

12.1. Autoconf iguracin Stateless

El procedimiento de autoconfiguracin stateless (sin intervencin o descu-brimiento automtico), ha sido diseado con las siguientes premisas:

Evitar la configuracin manual de dispositivos antes de su conexin a lared. Se requiere, en consecuencia, un mecanismo que permita a los hostobtener o crear direcciones nicas para cada una de sus interfaces,

asumiendo que cada interfaz puede proporcionar un identificador nicopara si misma (identificador de interfaz). En el caso ms simple, el identi-ficador de interfaz consiste en la direccin de la capa de enlace, de dicha


31/46

- 31 -

interfaz. El identificador de interfaz puede ser combinado con un prefijo,para formar la direccin.

Las pequeas redes o sitios, con mquinas conectadas a un nico enla-ce, no deberan requerir la presencia de un servidor stateful o router,como requisito para comunicarse. Para obtener, en este caso, caracters-

ticas plug & play, empleamos las direcciones de enlace local, dado quetienen un prefijo perfectamente conocido que identifica el nico enlacecompartido, al que se conectan todos los nodos. Cada dispositivo formasu direccin de enlace local anteponiendo el prefijo de enlace local a suidentificador de interfaz.

En el caso de redes o sitios grandes, con mltiples subredes y routers,tampoco se requiere la presencia de un servidor de configuracin de di-recciones stateful, ya que los host han de determinar, para generar susdirecciones globales o de enlace local, los prefijos que identifican las sub-redes a las que se conectan. Los routers generan mensajes peridicos

de anunciacin, que incluyen opciones como listas de prefijos activos enlos enlaces.

La configuracin de direcciones debe de facilitar la renumeracin de losdispositivos de un sitio, por ejemplo, cuando se desea cambiar de pro-veedor de servicios. La renumeracin se logra al permitir que una mismainterfaz pueda tener varias direcciones, que recibe en prstamo. Eltiempo del prstamo es el mecanismo por el que se renuevan las direc-ciones, al expirar los plazos para las viejas, sin que se conceda una pr-rroga. Al poder disponer de varias direcciones simultneamente, permiteque la transicin no sea disruptora, permitiendo que ambas, la vieja y lanueva direccin den continuidad a la comunicacin durante el perodo detransicin.

Slo es posible utilizar este mecanismo en enlaces capaces de funcionesmulticast, y comienza, por tanto, cuando es iniciada o activada una inter-faz que permite multicast.

Los administradores de sistemas necesitan la habilidad de especificarque mecanismo (stateless, stateful, o ambos), deben ser usados. Losmensajes de anunciacin de los routers incluyen indicadores para estafuncin.

Los pasos bsicos para la autoconfiguracin, una vez la interfaz ha sido ac-

tivada, seran:a) Se genera la direccin tentativa de enlace local, como se ha descritoantes.

b) Verificar que dicha direccin tentativa puede ser asignada (no estaduplicada en el mismo enlace).

c) Si esta duplicada, la autoconfiguracin se detiene, y se requiere un pro-cedimiento manual (por ejemplo, usando otro identificador de interfaz).

d) Si no esta duplicada, la conectividad a nivel IP se ha logrado, al asig-narse definitivamente dicha direccin tentativa a la interfaz en cues-tin.

e) Si se trata de un host, se interroga a los posibles routers para indicar al

host lo que debe de hacer a continuacin.f) Si no hay routers, se invoca el procedimiento de autoconfiguracin sta-

teful.


32/46

- 32 -

g) Si hay routers, estos contestarn indicando fundamentalmente, comoobtener las direcciones si se ha de utilizar el mecanismo stateful, uotra informacin, como tiempos de vida, etc.

Hay algunos detractores de este mecanismo, ya que implica que cualquier

nodo puede ser identificado en una determinada red si se conoce su identificadorIEEE (direccin MAC). Por ello, para permitir que la direccin no sea esttica, seesta trabajando en el documento draft-ietf-ipngwg-addrconf-privacy-01.txt.

12.2. Autoconf iguracin Stateful DHCPv6 (draft-ietf-dhc-dhcpv6-15.txt)

DHCP para IPv6 es un protocolo UDP cliente/servidor, diseado para redu-cir el coste de gestin de nodos IPv6 en entornos donde los administradores pre-cisan un control sobre la asignacin de los recursos de la red, superior al facilita-dos por el mecanismo de configuracin stateless.

Como ya hemos indicado, ambos mecanismos pueden usarse de formaconcurrente para reducir el coste de propiedad y administracin de la red.

Para lograr este objetivo, se centraliza la gestin de los recursos de la red,tales como direcciones IP, informacin de encaminado, informacin de instalacinde Sistemas Operativos, informacin de servicios de directorios, sobre uno o va-rios servidores DHCP, en lugar de distribuir dicha informacin en ficheros de con-figuracin locales en cada nodo.

Adems, DHCP ha sido diseado para ser fcilmente extensible con nue-

vos parmetros de configuracin, a travs de extensiones que incorporan estanueva informacin. Al respecto es fundamental el documento dhc-v6exts-12.txt.

Los objetivos de DHCPv6 son:

DHCP es un mecanismo, no una poltica. La poltica es establecida por eladministrador de la red y DHCP le permite propagar los parmetros ade-cuados, segn dicha poltica.

DHCP es compatible, lgicamente, con el mecanismo de autoconfiguracinstateless.

DHCP no requiere configuracin manual de parmetros de red en clientes

DHCP, excepto en casos donde dicha configuracin se requiere debido amedidas de seguridad.

DHCP no requiere un servidor en cada enlace, dado que debe funcionar atravs de rels DHCP.

DHCP coexiste con nodos configurados estticamente, as como con im-plementaciones existentes en la red.

Los clientes DHCP pueden operar en enlaces donde no hay routers IPv6.

Los clientes DHCP proporcionan la habilidad de renumerar la red.

Un cliente DHCP puede hacer mltiples y diferentes peticiones de parme-tros de configuracin, de uno o varios servidores DHCP simultneamente.

DHCP proporciona suficiente informacin para permitir a los servidoresDHCP el seguimiento del estado de configuracin de los clientes.


33/46

- 33 -

DHCP incorpora los mecanismos apropiados de control de tiempo y re-transmisiones para operar eficazmente en entornos con una alta latenciay/o reducido ancho de banda.

Los cambios fundamentales entre DHCPv4 y DHCPv6, estn basados en el

soporte inherente del formato de direccionamiento y autoconfiguacin IPv6; sonlas siguientes:

La direccin de enlace local permite a un nodo tener una direccin tanpronto como arranca, lo que significa que todos los clientes tienen una di-reccin IP fuente para localizar un servidor o rel en su mismo enlace.

Los indicadores de compatibilidad BOOTP y broadcast han desapareci-do.

El multicast y los mbitos de direccionamiento permiten el diseo de pa-quetes de descubrimiento, que definen por si mismos su rango por la di-reccin multicast, para la funcin requerida.

La autoconfiguracin stateful ha de coexistir e integrarse con la stateless,soportando la deteccin de direcciones duplicadas y los dos tiempos devida de IPv6, para facilitar la renumeracin automtica de direcciones ysu gestin.

Se soportan mltiples direcciones por cada interfaz.

Algunas opciones DHCPv4 ya no son precisas, debido a que los parme-tros de configuracin se obtienen a travs de ND o del protocolo de loca-lizacin de servicios (RFC2165).

De esta forma, se soportan las siguientes funciones nuevas:

Configuracin de actualizaciones dinmicas de DNS. Desaprobacin de direcciones, para renumeracin dinmica.

Rels preconfigurados con direcciones de servidores, o mediante multi-cast.

Autenticacin.

Los clientes pueden pedir mltiples direcciones IP.

Las direcciones pueden ser reclamadas mediante el mensaje de iniciar-reconfiguracin.

Integracin entre autoconfiguracin de direcciones stateless y state-

ful Permitir rels para localizar servidores fuera del enlace.

12.3. Renumeracin

En los prrafos anteriores ya hemos descrito el mecanismo bsico de re-numeracin, basado en el prstamo o alquiler de direcciones, en las fases depreferida y desaprobada, y en el tiempo de vida de las mismas.

En cualquier caso, podemos describir el mecanismo de forma sencilla, co-mo consistente en disminuir el tiempo de vida del prefijo en los paquetes de anun-ciacin del router, de forma que las direcciones pasen a ser desaprobadas, frentea las nuevas, que pasan a ser preferidas.


34/46

- 34 -

Sin embargo, este mecanismo est bsicamente diseado para los host.En el caso de los routers, se trabaja en un nuevo documento draft-ietf-ipngwg-router-renum-10.txt, que permitir mecanismos similares y ms adecuados.

13. IPv6 sobre Ethernet (RFC2464)

Aunque ya han sido definidos protocolos para permitir el uso de IPv6 sobrecualquier tipo de red o topologa (Token Ring, FDDI, ATM, PPP, ...), como ejem-plo mucho ms habitual y bsico, centraremos este apartado en Ethernet(CSMA/CD y tecnologas full-duplex basadas en ISO/IEC8802-3). Mas adelante,en este mismo documento, citaremos los protocolos adecuados para cada una delas otras tecnologas.

Los paquetes IPv6 se transmiten sobre tramas normalizadas Ethernet. Lacabecera Ethernet contiene las direcciones fuente y destino Ethernet, y el cdigode tipo Ethernet con el valor hexadecimal 86DD.

El campo de datos contiene la cabecera IPv6 seguida por los propios da-tos, y probablemente algunos bytes para alineacin/relleno, de forma que se al-cance el tamao mnimo de trama para el enlace Ethernet.


Direccin Ethernet Destino Direccin Ethernet Fuente 1000011011011101(86DD)

Cabecera y datos IPv6

El tamao mximo de la unidad de transmisin (MTU), para IPv6 sobre Et-hernet, es de 1.500 bytes. Evidentemente, este puede ser reducido, manual o au-

tomticamente (por los mensajes de anunciacin de routers).

Para obtener el identificador de interfaz, de una interfaz Ethernet, para laautoconfiguracin stateless, nos basamos en la direccin MAC de 48 bits(IEEE802). Tomamos los 3 primeros bytes (los de mayor orden), y les agregamosFFFE (hexadecimal), y a continuacin, el resto de los bytes de la direccin MAC(3 bytes). El identificador as formado se denomina identificador EUI-64 (Identifi-cador Global de 64 bits), segn lo define IEEE.

El identificador de interfaz se obtiene, a continuacin, partiendo del EUI-64,complementando el bit U/L (Universal/Local). El bit U/L es el siguiente al de menor

valor del primer byte del EUI-64 (el 2 bit por la derecha, el 2 bit de menor peso).Al complementar este bit, por lo general cambiar su valor de 0 a 1; dado que seespera que la direccin MAC sea universalmente nica, U/L tendr un valor 0, ypor tanto se convertir en 1 en el identificador de interfaz IPv6.


35/46

- 35 -

Una direccin MAC configurada manualmente o por software, no deberaser usada para derivar de ella el identificador de interfaz, pero si no hubiera otrafrmula, su propiedad debe reflejarse en el valor del bit U/L.

Vase el esquema siguiente:

Para mapear direcciones unicast IPv6 sobre Ethernet, se utilizan los meca-nismos ND para solicitud de vecinos.

Para mapear direcciones multicast IPv6 sobre Ethernet, se emplean los 4ltimos bytes de la direccin IPv6, a los que se antepone 3333.

14. Multi-homing

Como venimos viendo, el mecanismo de asignacin de direcciones IPv6 estotalmente jerrquico.

El multi-homing (mltiples hogares) es el mecanismo por el cual un de-terminado sitio o red puede estar conectado a otros por mltiples caminos, porrazones de seguridad, redundancia, ancho de banda, balanceo de carga, etc.

Dado que un determinado sitio utiliza el prefijo de su ISP, o proveedor denivel superior, un sitio puede ser multi-homed simplemente teniendo varios prefi-jos. Frecuentemente, cada prefijo estar asociado a diferentes conexiones fsicas,aunque no necesariamente, dado que se puede tratar de una sola conexin fsicay diversos tneles o conexiones virtuales.

Bit U/L

3 4 5 6 7 8 9 A B C D E

0 0 1 1 0 1 0 0

0 0 1 1 0 1 1 0

3 4 5 6 7 8 9 A B C D E

F F F E

3 6 5 6 7 8 9 A B C D EF F F E

Direccin MAC

Direccin EUI-64

Identificador de Interfaz


36/46

- 36 -

La problemtica se plantea por la dificultad de que un host decida, en unared multi-homed, que direccin fuente utilizar.

Algunos de los documentos sobre los que se est trabajando en este cam-po son:

Default Address Selections for IPv6 (draft-ietf-ipngwg-default-addr-select-00.txt).

IPv6 Multi-homing with Route Aggregation (draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt).

Multi-homed Routing Domain Issues for IPv6 (draft-ietf-ipngwg-multi-isp-00.txt).

15. IPsec

Una de las grandes ventajas de IPv6 es, sin duda, la total integracin de losmecanismos de seguridad, autenticacin y confidencialidad (encriptacin), dentrodel ncleo del protocolo.

Se trata por tanto de algo obligatorio, y no adicional ni aadido como enIPv4. Para ello, la siguiente cabecera puede tener valores AH (autenticacin Authentication Header) y ESP (encriptacin Encapsulation Security Payload),que permiten, bsicamente, emplear las mismas extensiones de protocolo em-pleadas en IPv4, y que de hecho, al haber sido desarrolladas con posterioridad alinicio de los trabajos de IPv6, ya lo contemplan.

Dado que los mecanismos asociados ya han sido descritos, simplementecitamos las normas bsicas que son aplicables: RFC2401 al RFC2412 yRFC2451.

16. Movilidad

La posibilidad de que un nodo mantenga la misma direccin IP, a pesar de

su movilidad, es otra de las motivaciones bsicas de IPv6. Como no, ya se haniniciado trabajos al respecto en IPv4, pero las complicaciones para usar la movili-dad en este caso son enormes.

2001:b00:bbbb::/48

2001:c00:cccc::/482001:a00:aaaa::/48

ISP A

2001:c00::/24

ISP A

2001:b00::/24

ISP A

2001:a00::/24

Sitio

multihomed

Internet


37/46

- 37 -

El documento base de estos trabajos es draft-ietf-mobileip-ipv6-12.txt. Laidea bsica permite identificar a un nodo mvil por su direccin de partida (homeaddress), independientemente de su punto de conexin a Internet en cada mo-mento dado. Por supuesto, cuando no esta en su punto de origen o de partida,tambin esta asociado con la informacin que permite identificar su posicin o

direccin actual (care-of-address). Los paquetes enviados a un nodo mvil (a sudireccin de origen), son transparentemente encaminados a su direccin actual.

El protocolo tambin permite que los nodos IPv6 almacenen la informacinde vinculacin entre la direccin de partida y la posicin actual, a modo de cach,y por tanto sean capaces de enviar los paquetes destinados al nodo mvil, direc-tamente a su direccin actual.

Para ello, el protocolo define nuevas opciones de destino, una de las cua-les ha de ser soportada incluso en paquetes recibidos por todos los nodos (aun-que no sean mviles).

Adems, hay que prever, dada la estructura habitual de las redes inalm-bricas (ejemplo muy habitual, la telefona celular), que un nodo mvil puede estarconectado simultneamente a varias redes (varas clulas que se solapan), y de-be de ser alcanzable por cualquiera de ellas.

Los trabajos iniciales estn documentados en el RFC2002 (soporte de mo-vilidad en IP) y sucesivos. Adems, se han publicado ya las especificaciones paratneles inversos en redes IP mviles (RFC2344), en cuya actualizacin se estatrabajando (draft-ietf-mobileip-rfc2344-bis-01.txt).

Se trabaja tambin en apartados como los requisitos de autenticacin, au-torizacin y facturacin (draft-ietf-mobileip-aaa-reqs-03.txt), comnmente denomi-nadas AAA (Authentication, Authorization and Accounting), las extensiones deautenticacin (draft-ietf-mobileip-challenge-09.txt), las claves de registro AAA(draft-ietf-mobileip-aaa-key-01.txt), la optimizacin de rutas (draft-ietf-mobileip-optim-09.txt), claves de registro para la optimizacin de rutas (draft-ietf-mobileip-regkey-01.txt), registros regionales (draft-ietf-mobileip-reg-tunnel-02.txt), entreotros.

17. DNS (RFC1886)

El mecanismo fundamental por el cual nos referimos a direcciones IP parala localizacin de un host, es el uso de literales (URL), como ya hemos anticipadoen apartados anteriores.

Sin embargo, para que este mecanismo funcione, a ms bajo nivel existeun protocolo denominado Sistema de Nombres de Dominio (Domain Name Sys-tem o DNS).

Este mecanismo, definido para IPv4 (RFC1034 y RFC1035), fue actualiza-do por el RFC1886, bsicamente incluyendo un nuevo tipo de registro para alma-cenar las direcciones IPv6, un nuevo dominio para soportar las localizaciones(lookups) basadas en IPv6, y definiciones actualizadas de tipos de consultas exis-tentes que devuelven direcciones Internet como parte de procesos de seccionesadicionales.


38/46

- 38 -

Las extensiones han sido diseadas para ser compatibles con las aplica-ciones existentes y, en particular, con las implementaciones del propio DNS.

El problema del sistema de DNS existente es fcilmente comprensible: Alhacer una consulta, las aplicaciones asumen que se les devolver una direccin

de 32 bits (IPv4). Para resolverlo, hay que definir las siguientes extensiones, an-tes indicadas:

Un nuevo tipo de registro de recurso para mapear un nombre de dominiocon una direccin IPv6: Es el registro AAA

tutorial de ipv6

Documents

reducido espacio de

creadores de ipv4

ampliaciones de ipv4

porqu ipv6

problemas de ipv4 permanecera

padre de internet

protocolo bsico

falta de direcciones