Introduccion IPV6 - Alejandro Corletti

Los Pases de habla hispana podemos ser pioneros en IPv6,
por mi parte tengo toda la FE puesta en que es posible.
IP versin 6 (Parte 01) - Sus componentes.

Madrid, abril de 2013.
Por: Alejandro Corletti Estrada (acorletti@darFe.es - acorletti@hotmail.com)

1. Presentacin.

Con este primer artculo, damos inicio a una serie cuya intencin es la de completarla
poco a poco hasta agotar el tema de IP versin 6 (tambin llamado IP Next Generation:
IPNG).
No desarrollaremos aspectos histricos o evolucin del mismo, pues ya est
suficientemente documentado este aspecto, sino su explicacin eminentemente tcnica,
basndonos en las RFCs (Request for Comments) que lo describen y sobre todo en el
anlisis de trfico presentando tramas, ejemplos concretos y casos prcticos de su
funcionamiento.
Una vez ms hacemos este sencillo aporte para la libre descarga y difusin en Internet, con
la nica intencin de colaborar en el conocimiento detallado de esta nueva tecnologa y
con mucha (pero mucha.) esperanza que en esta parte del mundo de habla hispana
seamos capaces de mojarnos, involucrarnos y aunar esfuerzos para demostrar que
somos capaces de liderar o al menos formar parte activa en los avances tecnolgicos (este
ser el lema y objetivo de toda esta serie).
Como se menciona en el pie de pgina, esta vez no es cuestin de inversiones monetarias,
ya la gran mayora de dispositivos soportan este conjunto de normas, slo es necesario
ponernos de acuerdo, presionar a las operadoras de telecomunicaciones, a los organismos
oficiales y sobre todo poner nuestro esfuerzo (tal vez tambin desinteresadamente) para
lograr esta vez lo que no fuimos capaces con la versin 4 de participar en las decisiones
globales demostrando que este ENORME porcentaje de poblacin mundial sabe a lo que
est enfrentando, posee los conocimientos y experiencia necesaria, y desea verse
involucrado compartiendo lo que tiene instalado y en produccin. en vez de recibir las
migajas (aunque suene duro) que estn dispuestos a ofrecernos.
Os invitamos a unir esfuerzos, voluntades y FE para lograrlo
La poblacin de habla hispana nativa es un 1,3% mayor que la de habla inglesa

Todos los artculos estarn estructurados de la siguiente forma:
1. Presentacin.
2. Introduccin.
3. Desarrollo.
4. Capturas de trfico ejemplos.

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 1
La poblacin de habla hispana nativa es un 1,3% mayor que la de habla inglesa.
2. Introduccin.

Si tuviramos que enfrentar el desafo de realizar una reforma estructural, por ejemplo en
el tercer piso de un gran edificio de cinco plantas de unos 30 aos de antigedad. Si en
esa planta furamos a colocar el doble de oficinas, muros de separacin, maquinarias,
cableado, servicios, acondicionadores de aire, etc es indudable que semejante reforma
impactara en varios aspectos del resto del edificio, por ejemplo debera contemplarse:
Reforzar los muros de las plantas inferiores (pues soportaran mucho ms peso).
Cambiar la dimensin de su cableado desde el cuadro central.
Ampliar los accesos de voz y datos del edificio.
Modificar escaleras, ascensores, vas de evacuacin.
Es posible tambin que si, supongamos, en las plantas superiores, existe personal
que deba comunicarse con los del tercer piso y ahora esos son cuatro veces ms,
pues a estos superiores deberamos de alguna forma permitirles interactuar o
asignar tareas a una planta con 4 veces ms personas.
Podramos seguir bastante ms con este supuesto..
Si profundizramos detalladamente en esta reforma, la conclusin evidente es que cuando
se lanza un desafo de este tipo, el mismo no queda acotado nicamente a esa planta sino
que impacta en mayor o menor medida en las inferiores y superiores.
Cuando hablamos del desafo que nos propone esta nueva versin del protocolo IP, el
resultado es exactamente el mismo. Es decir, un cambio radical sobre la estructura de una
nueva versin de un protocolo fundamental como es IP, s o s debe generar algunos
cambios en los pisos superiores e inferiores de esta pila, familia o modelo TCP/IP (o
tambin llamado Darpa).
Como el nombre de este artculo lo indica, comenzaremos esta serie, describiendo
brevemente todo el conjunto de componentes (o protocolos) que tambin necesitan
sufrir modificaciones en virtud de esta nueva versin, todos ellos tambin reciben la
denominacin de Versin 6 y son los que presentaremos en el desarrollo de este texto.
Al igual que en el ejemplo de la reforma de construccin, decidimos iniciar estos artculos,
con la visin global del edificio, para poder comprender todo el conjunto que se ve
implicado, una vez tenida esta visin lejana del problema, seguiremos adelante entrando
en el detalle de cada uno de ellos durante los prximos artculos.

3. Desarrollo.

Recordando el modelo de cinco capas que siempre hemos propuesto (ver y/o descargar
por Internet el libro Seguridad por Niveles), encontramos los siguientes niveles:
Nivel 1: Fsico.
Nivel 2: Enlace.

Nivel 3: Red.
Nivel 4: Transporte.
Nivel 5: Aplicacin.

La nueva versin del protocolo IP presenta los siguientes cambios principales:
Encabezado mnimo de 40 Bytes (frente al mnimo de 20 de la versin 4).
Campo de direcciones de 128 bits (frente a los 32 de la versin 4).
Responsable de la determinacin MTU (Unidad de transporte mximo) (Tema
que se encargaba TCP en la versin 4).
Diferentes opciones para la asignacin dinmica de direcciones (No solo DHCP:
Dynamic Host Configuration Protocol).
No existe el concepto de Broadcast y aparece uno nuevo llamado Anycast (y
esto afecta el nivel de enlace)
Nueva funcionalidad para determinar la unidad mxima de transmisin de
informacin (MTU) para evitar la fragmentacin en nodos intermedios.
IPSec como funcionalidad nativa de IPv6 (Es la nica metodologa de tnel
aprobada por IETF (Internet Engineering Tsak Force).
Agrega 20 bytes ms para QoS (Flow level), que se suman a los 8 bits
originales de IPv4 que slo cambian de nombre y ahora se llaman Traffic class.
Elimina:
o La capacidad de fragmentacin que tena IPv4, por lo tanto elimina todos
esto campos (Ahora es una cabecera en extensin y solo se puede realizar en
origen y destino, NO en nodos intermedios).
o Longitud de cabecera (Ahora se llama payload Lenght y es la longitud del
campo de datos, incluyendo cabeceras de extensin).
o Control de errores de cabecera
o Opciones

A continuacin presentaremos los protocolos y recomendaciones que estn asociadas a
este nuevo diseo. Tal cual se expres al principio, en este primer artculo slo se har la
presentacin inicial con el objetivo de comprender todos los Componentes de este
cambio, en los prximos artculos se ir profundizando en cada uno de ellos.
Cada uno de estos cambios impacta a sus vecinos, concretamente en los siguiente
aspectos:

a. Nivel de transporte

El encabezado mnimo de 40 Bytes, (el doble que la versin 4) afecta
principalmente dos temas del nivel de transporte, su primer problema est

relacionado con el control de ventana de envo y recepcin para el caso de TCP, el

segundo al control de errores por una especie de apao que se puede ejecutar
sobre los protocolos de nivel 4 TCP y UDP a travs del concepto de pseudo
encabezado, en el cual se solapaban bits del encabezado de IP con TCP o UDP, al
modificar el tamao del encabezado IP, esto afecta concretamente a TCP y UDP y se
consideran estas nuevas metodologas como:

UDPv6:
TCPv6:
Si bien se debe aclarar que no existen RFC que los proclamen como versin 6.

En TCP, sin lugar a dudas el mayor impacto pasa por que se cuadruplica el trabajo
sobre la tcnica de Ventana deslizante (para profundizar, ver libro Seguridad
por Niveles); sobre nodos que soportan muchas sesiones simultneas, esto es un
impacto importante, pues ahora debe analizar y almacenar Sockets compuestos
por una concatenacin de direccin IP + puerto (origen y destino) cuatro veces
mayor, por lo tanto este incremento no es trivial, de hecho a mi juicio es donde
mayor tarea de anlisis de impacto de se deber realizar y seguramente un nuevo
dimensionamiento de estos servicios. Por otro lado (ser para compensar?) se
aliviana la tarea del clculo de la MTU que es una actividad tpica de TCP sobre
IPv6.

Otro aspecto a mencionar en este nivel es un nuevo concepto que se denomina
Jumbogramas definidos en la RFC 2675, esta recomendacin tiene su base en la
calidad de los vnculos de comunicaciones actuales (particularmente la fibra
ptica) que en virtud de la bajsima tasa de errores, permite el empleo de
inmensas unidades de informacin en un solo bloque pues la probabilidad de
tener que retransmitirla es casi despreciable, por lo tanto se puede minimizar el
empleo de muchos encabezados de paquetes pequeos y aprovechas para enviarlos
todos en uno slo Enorme Jumbograma. Este hace uso de un campo de
opciones y permite llevar el concepto de Payload con 32 bits, lo que equivale a
unos 4.000.000 de Bytes en el campo de datos, de estos mensajes. Por ejemplo su
uso es ideal en vnculos de sincronismo entre clusters, dispositivos de alta
disponibilidad, backups internos, etc.

En el caso de UDP la idea es similar, exceptuando el tema de la ventana deslizante,
que no aplica a este protocolo.

No hay cambios en los encabezados ni aparecen nuevas RFCs del tipo TCPv6 y/o
UDPv6, pero como se acaba de desarrollar, s implica cambios y ajustes en sus
lgicas de funcionamiento. Una RFC que hace referencia a las nuevos puertos y
opciones para TCP y UDP (tambin lo hace como se puede apreciar para ICMP e IP)
es la que figura a continuacin:
Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6,
4727
UDP, and TCP Headers Proposed Standard (PS)

b. Aspectos que impactan en el nivel de enlace/fsico:


1) Protocolo ND (Network Discovery).

Este nuevo protocolo que aparece de la mano de IPv6, podramos decir que es el
que reemplaza el empleo de ARP (Address Resolution Protocol), pero tambin
asume funciones de DHCP (Dynamic Host Configuration Protocol), se encuentra
regulado por las siguientes RFC:
Extensions to IPv6 Neighbor Discovery for Inverse
3122 Proposed Standard (PS)
Discovery Specification

Neighbor Discovery for IP version 6 (IPv6) 4861 Internet Standard (STD)

Certificate Profile and Certificate Management for SEcure
Neighbor Discovery (SEND)
Subject Key Identifier (SKI) SEcure Neighbor Discovery
(SEND)
Neighbor Discovery Optimization for IPv6 over Low-
Power Wireless Personal Area Networks (6LoWPANs)
Algunas de las funciones ms importantes que realiza son:

- Descubrimiento de routers, prefijos de red, parmetros (como MTU).
- Participar en la obtencin de direcciones IP de forma dinmica.
- Mapeos de direcciones MAC a direcciones IP.
- Determinacin del prximo salto.
- Deteccin de direcciones IP duplicadas.
- Redireccin de rutas.
- Muy importantes son los conceptos de SEND (RFCs: 6494 y 6495)
pensados para evitar los conocidos ataques sobre direccionamiento
MAC.
2) Especificaciones sobre protocolos de nivel enlace/fsico ya existentes.

Tal cual iniciamos este artculo, podemos estar seguros que existen cambios en
los cimientos de este modelo. Las diferentes metodologas de acceso al
modelo de capas actualmente se encuentran todas definidas para soportar IPv6.
En la actualidad la gran mayora de las tarjetas de red ya vienen con
funcionalidades para IPv6. En nuestra opinin, la parte fsica de estos
elementos, no sufre modificaciones, las mismas en general van relacionadas a
nuevos parmetros de diseo relacionados a la velocidad de ese vnculo fsico
(nuevos conectores, modulacin, codificacin de bits, multiplexacin, etc.) pero
no en el uso o no de IPv6. Dnde s vemos cambios es en el nivel de enlace.
En particular, una de los mayores objetivos de IPv6 (y es tal vez su
desencadenante) es la telefona mvil, actualmente ha puesto en evidencia la
escasez de direccionamiento IPv4. El primer paso sin duda fue que los
dispositivos Smart pone pudieran acceder a la red con todo un modelo de
capas TCP/IP y las mismas prestaciones que un ordenador, para ello crecieron
de forma acelerada las generaciones de acceso a la red mvil (2G, 2.5G, 3G, 3.XG
y ya est lista 4G=LTE [Long Term Evolution]). El protocolo IPv6 tiene como
una de sus mayores fortalezas de direccionamiento, un fuerte vnculo con las
direcciones MAC (lo veremos en detalle en artculos posteriores, bajo las
normas relacionadas a EUI-64), por esa razn es que hoy cualquier Smart

phone ya trae su propia tarjeta MAC con su numeracin nica a nivel mundial,
a continuacin mostramos imgenes de dos de estos dispositivos:

Firefox.OS Nexus-Galaxy
Como pueda apreciarse en ambas imgenes su tarjeta y direccionamiento MAC
ya la trae configurada y como estndar global de IEEE, este es nico en el
mundo (Para ampliar detalles ver libro Seguridad por Niveles).
Cuando desarrollemos este tema se profundizar, por ahora podemos ir
anticipando que las pruebas que realizamos desde diferentes dispositivos
mviles fueron las siguientes:
Instalamos un punto de acceso WiFi, habilitando IPv6, deshabilitando
DHCPv4 y habilitando DHCPv6 como se presenta en la siguiente imagen:

Fuimos probando conexiones con diferentes telfonos mviles con el

siguiente resultado:
N Equipo Estado
Telfono: Galaxy-Nexus
1 SO: Android 4.2 Kernel 3.0.31 No conect
Aplicacin WiFi por defecto
Telfono: Samsung GT-S5830i
SO: Android 2.3.6 Kernel 2.6.35.7
2 No conect
Aplicacin WiFi: Ipv6 Config (no permiti
su instalacin : kernel no lo soportaba)
3 Telfono: i pone 4 No conect
Telfono: Samsung Galaxy SIII
4 SO: Android 4.1.2 Kernel 3.0.31 No conect
Aplicacin WiFi por defecto
Telfono: Nokia N-900 Conect sin
5 SO: Linux Kernel 2.6.28.10-Power50 problemas y se le
Aplicacin WiFi por defecto asign una IP v6
En el caso de una conexin tambin WiFi a este mismo punto de acceso, pero
desde una mquina Windows, se puede vera a continuacin que no ha habido
ningn inconveniente:
Adaptador de LAN inalmbrica Conexin de red inalmbrica:
Sufijo DNS especfico para la conexin. . :
Descripcin . . . . . Qualcomm Atheros QCA9565 802.11b/
g/n WiFi Adapter
Direccin fsica. . . . . . . . . . . . . : 20-68-9D-09-70-75
DHCP habilitado . . . . . . . . . . . . . : s
Configuracin automtica habilitada . . . : s
Vnculo: direccin Ipv6 local. . . : fe80::f192:133b:6680:d632%13(Preferido)
Puerta de enlace predeterminada . . . . . : fe80::21f:a4ff:fe91:8092%13
IAID DHCPv6 . . . . . . . . . . . . . . . : 287336605
DUID de cliente DHCPv6. . . : 00-01-00-01-18-80-38-73-28-92-4-28-E6-13
Servidores DNS. . . . . . . . . . . . . . : fe80::21f:a4ff:fe91:8092%13
NetBIOS sobre TCP/IP. . . . . . . . . . . : habilitado
(ms adelante explicaremos todos los campos)
En realidad lo que queremos presentar con estas pruebas es el hecho que, tal
cual vemos en el trabajo realizado, la tecnologa SOPORTA Ipv6 pero hace falta:
voluntad y esfuerzo en actualizarlos, instalar aplicaciones, configurar
dispositivos, etc. Nos pareci oportuno incluir estas pruebas en este primer
artculo, slo para despertar el inters, en este caso con la telefona mvil.
Cuando publiquemos el artculo referente al nivel de enlace con IPv6 estarn en
el mismo todos los detalles y el trabajo completo que hemos realizado.
Sobre la base de este direccionamiento (MAC) en los dispositivos mviles a
nivel de enlace, es que se puede seguir avanzando para su total adaptacin,
primero hacia IPv4 de forma no tan dependiente (entre IP y MAC) y luego sobre
IPv6 con una relacin mucho ms estrecha.

Al slo efecto de presentar brevemente estas novedades de IPv6 respecto al

nivel de enlace (reiteramos, todo el detalle ser desarrollada en artculos
posteriores), tomemos por ejemplo la primera de la RFC que figuran ms abajo:
RFC-2464, la misma al principio ya define (en su punto 3. Frame Format) que
el formato de las tramas Ethernet seguir siendo el mismo, pero introduce un
nuevo valor para su campo Ethertype que ser 86Ddh
(100001011011101). Luego en el punto 4 (Stateless Autoconfiguration)
describe al detalle cmo esta direccin MAC (EUI-48) se trabaja para
transformarla en lo necesario para dar origen a una direccin IPv6 (se
transforma a formato EUI-64) y sobre esto a su vez (tratado en el punto 5. Link
Local Addresses) se elabora la direccin de enlace local, que bajo este tipo de
configuracin se convertir (tal cual lo expresa en el punto 6. Address Mapping
Unicast) en este caso en su direccin IPv6 (para los que ya conocen algo del
tema, ser un prefijo del tipo FE80::/64), y en el punto 7. Address Mapping
Multicast describe como se constituye esta direccin IPv6 para las
transmisiones Multicast.
En resumen, lo que intentamos explicar en este punto es que para cada tipo de
nivel de enlace/fsico, existen una serie de recomendaciones que describen
cmo deber se tratado el mismo para poder entregar su payload de forma
efectiva al nivel superior cuando este sea IPv6.
A continuacin presentamos las RFCs que se relacionan con cada uno de ellos:
Transmission of Ipv6 Packets over Ethernet Networks 2464
Proposed Standard (PS)

Transmission of Ipv6 Packets over FDDI Networks 2467

Transmission of Ipv6 Packets over Token Ring Networks 2470

Ipv6 over ATM Networks 2492

Transmission of Ipv6 Packets over Frame Relay
2590
Networks Specification Proposed Standard (PS)

Transmission of Ipv6 Packets over IEEE 1394 Networks 3146

IP Version 6 over PPP 5072
Internet Standard (STD)

Address Mapping of Ipv6 Multicast Packets on Ethernet 6085 Proposed Standard (PS)

c. Protocolo ICMP (Internet Control Message Protocol) versin 6.

Este protocolo, como su nombre lo indica se emplea para el envo y recepcin de
mensajes de control, en particular de errores, conectividad, rutas, etc.
En el caso de la versin 6, se trata del protocolo que ms modificaciones sufre
dentro de este modelo (junto con DHCP). Su funcionamiento y encabezado sigue la
misma lgica de la versin anterior, una pequea diferencia es que ahora el campo
Protocol del paquete IP que invoca al protocolo de nivel superior se define con un
nuevo valor 58 (para ICMPv4 este valor era 01). Podramos decir que su
funcionamiento se contina basando en los dos campos: tipo y cdigo, pero
sobre estos dos mismos campos presenta o define un importante nmero de
opciones que antes no existan, en general todos estos los engloba en dos tipos:
Mensajes tipo error (valores del campo Type entre 0 y 127) y mensajes tipo
informacin (valores del campo Type entre 128 y 255). Lo nuevo en ellos est

relacionado a escuchas de multicast, solicitudes y advertencias de rutas y de

vecinos, informacin de nodos, prefijos mviles y caminos de certificacin.
El empleo del protocolo ND (mencionado anteriormente) est soportado a travs
de ICMPv6, y justamente aqu es donde tambin introduce esta funcionalidad de
SEND (Secure Neghbor Discovery).
Internet Control Message Protocol (ICMPv6) for the
4443 Internet Standard (STD)
Internet Protocol Version 6 (Ipv6) Specification

6791
Stateless Source Address Mapping for ICMPv6 Packets Proposed Standard (PS)
*

d. Protocolos de enrutado.

Es natural que si el campo de direccionamiento es el que mayor diferencia presenta
en el protocolo IPv6, todo lo relacionado a rutas y direcciones sea el rea donde
mayor trabajo se encuentra.
Respecto a los protocolos de enrutado, podemos mencionar las siguientes
recomendaciones:
RIPng for Ipv6 2080

BGP-MPLS IP Virtual Private Network (VPN) Extension
4659
for Ipv6 VPN Proposed Standard (PS)

Multiprotocol Extensions for BGP-4 4760 Draft Standard (DS)

Routing Ipv6 with IS-IS 5308 Proposed Standard (PS)
OSPF for Ipv6 5340 Proposed Standard (PS)
IANA Considerations for the Ipv4 and Ipv6 Router Alert
5350
Options Proposed Standard (PS)
Virtual Router Redundancy Protocol (VRRP) Version 3
5798
for Ipv4 and Ipv6 Proposed Standard (PS)
Ipv6 Traffic Engineering in IS-IS 6119 Proposed Standard (PS)
Ipv4 and Ipv6 Infrastructure Addresses in BGP Updates
6515
for Multicast VPN Proposed Standard (PS)
Ipv6 Multicast VPN (MVPN) Support Using PIM Control
Plane and Selective Provider Multicast Service Interface 6516
(S-PMSI) Join Messages Proposed Standard (PS)

En general estas nuevas versiones de protocolos de enrutado, ofrecen mayores
funcionalidades para descubrimiento de routers (parte de ND), de distancias,
saltos, por supuesto soporte para los nuevos 128 bits de direccionamiento (frente a
los 32 anteriores), nuevos puertos (para que permitan convivir ambas versiones),
interaccin/integracin directa con IPSec para seguridad (Autenticacin, acceso,
integridad, confidencialidad, trazabilidad, no repudio).
Un caso particular de denominacin es OSPF (Open Short Path First) para IPv6 que
es tambin conocido como OSPFv3 (en vez de ser v6), algo similar sucede con las
extensiones de BGPv4+.
Con IPv6 pierde sentido todo concepto de NAT (Network Address Translation) y
CIDR (Classless Inter Domain Routing), por lo tanto esto alivia de trabajo

sensiblemente a todos los elementos responsables del manejo de rutas y

creacin/mantenimiento de tneles.

e. DHCP (Dynamic Host Configuration Protocol)

Como ya hemos anticipado, este protocolo es tal vez el que mayor trabajo ha
ocasionado con la aparicin de IPv6. La aparicin de DHCP fue la evolucin natural
del protocolo Bootp (Boot Trap Protocol, para profundizar sobre esto ver libro
Seguridad por Niveles), luego tambin se relaciona con R_ARP (Reverse
Address Resolution Protocol) y para simplificar, ampliar y hacer ms amigable esta
configuracin nace DHCP. Esta sumatoria de ampliaciones (que hasta tal vez
podramos llamar parches) es la que se optimiza considerablemente con DHCPv6.
Se crean dos puertos nuevos para solicitudes y respuestas: UDP 546 y 547 (que en
DHCPv4 son: UDP 67 y 68), con la convivencia de estos cuatro puertos se permite el
funcionamiento de ambas versiones simultneamente (para transicin) pudiendo
contar en la misma red con los dos esquemas de direccionamiento dinmico a la
vez.
Cuando desarrollemos en detalle este protocolo, podremos comprender las
diferentes opciones que ofrece, tanto en lo relacionado a Autoconfiguracin de
direcciones, como al nuevo concepto que propone llamado Con y sin control de
estados que en definitiva permite que las configuraciones dinmicas puedan ser
ofrecidas tanto por servidores DHCP, como por los mismos routers de red, sin
llevar estos ltimos un control de las direcciones asignadas (por eso viene lo de
control de estados, o no).
La actividad de DHCPv6 guarda estrecha relacin con el nuevo protocolo
mencionado anteriormente ND, y entre ambos ofrecen toda una gama de
posibilidades anteriormente inexistentes con IPv4 que permiten solicitudes,
respuestas y advertencias (informacin) de rutas, vecinos, parmetros, servicios,
servidores, opciones de vendedores/fabricantes, etc.
El dilogo a travs del protocolo DHCP, como hemos mencionado ofrece los dos
nuevos puertos UDP y se realiza por medio de mensajes similares a la versin 4
(con la salvedad que ahora no existe el Broadcast por lo tanto este dilogo es
bastante ms dirigido) del tipo Solicitud/peticin/respuestas/informacin todos
ellos se identifican empleando el primer octeto de su encabezado. Hay que destacar
que ahora aparecen dos tipos de solicitudes: Solicit y Request habr que
ponerse de acuerdo, como lo llamaremos en castellano: mi propuesta ser
Solicitud y Peticin. Tambin tenemos mensajes de advertencia, confirmacin,
renegociacin, re-enlace, liberacin, rechazo, reconfiguracin, solicitud de
informacin, encaminamiento, relevo. Todos estos los desarrollaremos con
mximo detalle en artculos posteriores.
Las RFCs que hacen referencia a este nuevo protocolo son las que figuran a
continuacin:

Dynamic Host Configuration Protocol for Ipv6 (DHCPv6) 3315

Dynamic Host Configuration Protocol (DHCPv6) Options

3319
for Session Initiation Protocol (SIP) Servers Proposed Standard (PS)

Ipv6 Prefix Options for Dynamic Host Configuration

3633
Protocol (DHCP) ersin 6 Proposed Standard (PS)

DNS Configuration options for Dynamic Host

3646
Configuration Protocol for Ipv6 (DHCPv6) Proposed Standard (PS)

Stateless Dynamic Host Configuration Protocol (DHCP)

3736
Service for Ipv6 Proposed Standard (PS)

Network Information Service (NIS) Configuration

Options for Dynamic Host Configuration Protocol for 3898
Ipv6 (DHCPv6) Proposed Standard (PS)
Renumbering Requirements for Stateless Dynamic Host Informational
4076
Configuration Protocol for Ipv6 (DHCPv6) T
Information Refresh Time Option for Dynamic Host
4242
Configuration Protocol for Ipv6 (DHCPv6) Proposed Standard (PS)

Dynamic Host Configuration Protocol for Ipv6 (DHCPv6)

4580
Relay Agent Subscriber-ID Option Proposed Standard (PS)


4649
Relay Agent Remote-ID Option Proposed Standard (PS)

The Dynamic Host Configuration Protocol for Ipv6

(DHCPv6) Client Fully Qualified Domain Name (FQDN) 4704
Option Proposed Standard (PS)

Dynamic Host Configuration Protocol (DHCPv4 and
DHCPv6) Option for Civic Addresses Configuration 4776
Information Proposed Standard (PS)

DHCPv6 Relay Agent Echo Request Option 4994

DHCPv6 Leasequery 5007


DHCPv6 Bulk Leasequery 5460

Dynamic Host Configuration Protocol (DHCPv4 and
DHCPv6) Options for IEEE 802.21 Mobility Services 5678
(MoS) Discovery Proposed Standard (PS)
DHCPv6 Options for Network Boot 5970
DHCPv4 and DHCPv6 Options for Access Network
6153
Discovery and Selection Function (ANDSF) Discovery Proposed Standard (PS)
Lightweight DHCPv6 Relay Agent 6221
DHCPv6 Prefix Delegation for Network Mobility (NEMO) 6276
6334
Option for Dual-Stack Lite Proposed Standard (PS)
Definition of the UUID-Based DHCPv6 Unique Identifier
6355
(DUID-UUID) Proposed Standard (PS)
The EAP Re-authentication Protocol (ERP) Local Domain
6440
Name DHCPv6 Option Proposed Standard (PS)
Prefix Exclude Option for DHCPv6-based Prefix
6603
Delegation Proposed Standard (PS)
Virtual Subnet Selection Options for DHCPv4 and
6607
DHCPv6 Proposed Standard (PS)
DHCP Options for Home Information Discovery in Mobile
6610
Ipv6 (MIPv6) Proposed Standard (PS)
Rebind Capability in DHCPv6 Reconfigure Messages 6644

Best Current Practice

DHCPv6 Redundancy Deployment Considerations 6853
(BCP)

f. Relacionado a su nuevo rol de responsable de la determinacin MTU.

Como hemos comentado al principio esta actividad que con IPv4 era
responsabilidad del nivel de transporte, ahora recae en IPv6.
Se desarrolla con todo detalle en la RFC que mencionamos aqu debajo.
Path MTU Discovery for IP version 6 1981
Internet Standard (STD)
Hemos querido hacer una breve referencia de la misma en este punto pues implica
un cambio importante para este nuevo modelo. El funcionamiento se realiza
aprovechando un nuevo Tipo del protocolo ICMPv6 que es el tipo 2 combinado
con el cdigo 0, a continuacin presentamos este encabezado tal cual lo propone
la RFC 1981 en el punto: 3.2. Packet Too Big Message.
Type 2
Code Set to 0 (zero) by the originator and ignored by the receiver.
MTU The Maximum Transmission Unit of the next-hop link.
Como se puede apreciar el valor importante que viaja aqu es justamente el de

MTU que es la mxima unidad de informacin que podr soportar en el prximo
salto.
El encabezado de este tipo es el que figura a continuacin:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Por medio de este mensaje, la lgica de funcionamiento de IPv6, permite ir
controlando el tamao mximo de paquetes que entregar al nivel de enlace,
manteniendo un control peridico tanto para evaluar si puede aumentarlos como si
debe disminuirlos. Todo este detalle, tambin se desarrollar en artculos
posteriores.

g. Autenticacin/Control de acceso/Trazabilidad

El punto ms robusto para este tema pasa por su nativo diseo sobre IPSec, que es
el punto siguiente, pero tengamos en cuenta que existen protocolos de
Autenticacin/control de acceso/trazabilidad, que pueden interactuar entre la
direccin IP de usuario, su nombre y las direcciones IP destino a las cules podr o
no acceder, por lo tanto, si este esquema de direccionamiento cambia, entonces
necesariamente debe actualizarse su funcionamiento para poder mantener esta
lgica con la mxima granularidad, es decir pudiendo segmentar perfectamente
desde dnde se permite o no, a quin y hacia que direcciones IP, segmentos de red,
grupos de dispositivos, servidores, servicios, aplicaciones, etc.

Todas estas nuevas caractersticas aplican a los siguientes protocolos y se definen

en las RFC que figuran a continuacin:
RADIUS and IPv6 3162

RADIUS Authentication Client MIB for IPv6 4668

RADIUS Authentication Server MIB for IPv6 4669

RADIUS Delegated-IPv6-Prefix Attribute 4818

RADIUS Support for Proxy Mobile IPv6 6572 Proposed Standard (PS)
Kerberos Options for DHCPv6 6784 Proposed Standard (PS)
Diameter Mobile IPv6: Support for Network Access
5447
Server to Diameter Server Interaction Proposed Standard (PS)

Diameter Mobile IPv6: Support for Home Agent to

5778
Diameter Server Interaction Proposed Standard (PS)

Diameter Proxy Mobile IPv6: Mobile Access Gateway and

5779
Local Mobility Anchor Interaction with Diameter Server Proposed Standard (PS)

h. IPSec/tneles.

El tema IPSec es uno de los aspectos sobre los que ms centraremos la atencin en
esta serie de artculos, pues justamente, desde el punto de vista de seguridad (que
es lo que nos interesa) implica una nueva lgica de funcionamiento mucho ms
robusta. Sin desarrollar nada en esta primera presentacin, slo queremos dejar
sembrada la semilla de su importancia, IPSec es un conjunto de normas que ofrece
toda la gama de medidas necesarias para una verdadera comunicacin segura de
extremo a extremo, con certificados o sin ellos con clave pblica y privada, con
mecanismos slidos de claves (ISAKMP e IKE), con un encabezado adicional para IP
(AH) y con la posibilidad de criptografiar toda la informacin en el nivel superior a
IP (ESP). La nica reflexin que deseamos dejar pendiente es que a partir de ahora
qu rol ocuparn: toda la familias de TLS (SSL, https, sftp)?, SSH seguir siendo
necesario?.

Las RFCs que regulan esta familia son las siguientes:
Using IPsec to Protect Mobile IPv6 Signaling Between
3776
Mobile Nodes and Home Agents Proposed Standard (PS)

Network Information Service (NIS) Configuration

Options for Dynamic Host Configuration Protocol for 3898
IPv6 (DHCPv6) Proposed Standard (PS)

Mobile IPv6 Operation with IKEv2 and the Revised IPsec
4877
Architecture Proposed Standard (PS)
IPv6 Configuration in Internet Key Exchange Protocol 5739
Version 2 (IKEv2) * Experimental
Generic Routing Encapsulation (GRE) Key Option for 5845
Proxy Mobile IPv6 * Proposed Standard (PS)
Using Counter Modes with Encapsulating Security
6054
Payload (ESP) and Authentication Header (AH) to
*
Protect Group Traffic Proposed Standard (PS)
Using the IPv6 Flow Label for Equal Cost Multipath 6438
Routing and Link Aggregation in Tunnels * Proposed Standard (PS)

i. DNS (Domain Name System).


Todo el sistema de nombres de dominio se ve afectado, tanto en la resolucin
simple como en la inversa, se mantiene la misma lgica, pero ahora se est
implantando este desafo a travs de la convivencia de ambas versiones.
Las RFCs que lo regulan son las que figuran a continuacin:

DNS Extensions to Support IPv6 Address Aggregation
2874
and Renumbering Historic
DNSSEC and IPv6 A6 aware server/resolver message
3226
size requirements Proposed Standard (PS)
Representing Internet Protocol version 6 (IPv6)
3363
Addresses in the Domain Name System (DNS) Informational
Best Current Practice
Nameservers for IPv4 and IPv6 Reverse Zones 5855
(BCP)
IPv6 Router Advertisement Options for DNS
6106
Configuration Proposed Standard (PS)
DNS64: DNS Extensions for Network Address
6147
Translation from IPv6 Clients to IPv4 Servers Proposed Standard (PS)

j. NTP (Network Time Protocol)

La sincronizacin de tiempos es una actividad fundamental en los dispositivos de
una red, a pesar que la experiencia nos demuestra que no se le suele dar
importancia, la realidad es que a la hora de sufrir anomalas en una infraestructura,
es increble la cantidad de problemas que se presentan a la hora de analizarlos para
obtener conclusiones o intentar restaurarlos, en particular cuando se debe hacer
un anlisis forense. Este ser otro de los temas que le dedicaremos cierto espacio
en nuestros artculos, pues una ventaja para montar una verdadera jerarqua (o
estratos) de servidores de tiempo, es aprovechar el funcionamiento de DHCP.
Desde el punto de vista de seguridad hay varias medidas que deben conocerse pues
este tambin es un protocolo interesante para un intruso, por eso lo abordaremos
con cierto detalle.
Las RFCs que lo describen son:
Simple Network Time Protocol (SNTP) Configuration
4075
Option for DHCPv6 Proposed Standard (PS)

Network Time Protocol (NTP) Server Option for

5908
DHCPv6 Proposed Standard (PS)



En esta seccin presentaremos brevemente algunas capturas de trfico relacionadas a los
componentes que hemos descrito.

a. Neighbor Discovery

Como hemos mencionado, este es un nuevo protocolo que aparece con IPv6, trabaja en
estrecha relacin con ICMPv6, tanto es as que en la RFC 4861 Neighbor Discovery for
IP version 6 (IPv6) hace referencia a los nuevos Tipos y cdigos de ICMPv6 que se
definen para el funcionamiento de ND. En el punto 2.3. Addresses de esta RFC nos
menciona que Neighbor Discovery (ND) hace uso de un nmero de diferentes
direcciones (definidas en [ADDR-ARCH]), que incluyen:
all-nodes multicast address (Las direcciones de mbito local para alcanzar todos
los nodos). Esta direccin es: FF02::1.
Ms adelante describe que ND define cinco Tipos de paquetes: Solicitud de router
Advertencia de router Solicitud de Neighbor (vecino) - Advertencia de vecino -
mensaje de redireccin
A Continuacin presentamos un ejemplo de capturas justamente de este Neighbor
Advertisement que la misma RFC lo describe como una respuesta a una Solicitud de
Neighbor (que presentamos tambin como segunda imagen).
En el punto 4.4. Neighbor Advertisement Message Format la misma RFC describe el
formato de este mensaje:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-

No es intencin de este primer artculo entrar en este tipo de detalles, sencillamente
comenzar a presentar el trabajo y la metodologa de confrontacin entre el desarrollo
terico y la parte prctica, como en este caso las capturas de trfico, por esa razn
presentamos a continuacin una captura de este tipo de mensaje:


En la imagen anterior, podemos ver los puntos que destacamos de la RFC:
La direccin IPv6 Multicast: ff02::1
El protocolo ICMPv6
El type ICMPv6: Neighbor Advertisement (tipo 136)
Todos los campos presentados en el punto 4.4 de la RFC (formato del
mensaje): Tipo, cdigo, checksum, R S O.
Para ampliar un poco ms este protocolo, presentamos otra captura con el mensaje
relacionado al formato anterior : Tipo 135 Neighbor Solicitation.

Si alguien tiene intencin de profundizar an ms sobre ND, dejamos a continuacin

un par de capturas, esta vez relacionadas a mensajes de router (Tipo 133 y 134):


b. ICMPv6

Para cerrar un poco ms el punto anterior, presentamos algunas capturas tambin de
ICMPv6. En la siguiente imagen podemos apreciar una trama tpica de ICMP como es
la solicitud de eco (comando PING), que opera exactamente igual que la versin previa,
pero esta vez sobre ICMPv6:

Como podemos en ver la imagen anterior, el protocolo ICMP mantiene su formato
original, este vez sobre IPv6 y con la salvedad de este nuevo Tipo: 128 para la
solicitud, que en ICMPv4 es el tipo: 8. Reiteramos que estos nuevos valores son
definidos para mantener la convivencia entre ambas versiones y que no se solapen.

c. Nivel de enlace:

En la prxima captura presentamos como trabaja el nivel de enlace, en esta caso una
trama Ethernet, la cual, como hemos mencionado en el desarrollo no sufre ningn tipo
de cambios, excepto la asignacin de nuevos valores para el campo Ethertype que tal
cual podemos apreciar responde al valor 86 que hemos destacado en color naranja, y
por este solo aspecto es que desebamos incorporar esta captura.



d. DNSv6

Presentamos una solicitud y una respuesta DNS, en la segunda de ellas hemos dejado
visibles los campos de UDP donde nos muestra el valor 5353 como protocolo de nivel
superior, lo que abre el acceso a DNSv6. Este protocolo requerir varias pginas en
artculos posteriores.



e. DHCPv6

Las prximas dos capturas son del protocolos DHCPv6, en la primera hemos dejado la
imagen del nivel de transporte para que se puedan ver esos nuevos valores (546 y
547) que se definieron para el acceso a DHCPv6 y poder mantener el 67 y 68 para la
versin 4 tal cal mencionamos en el desarrollo.


f. http (Hiper Text Transfer Protocol

Si bien sobre este protocolo no existen cambios, nuevamente encontramos ciertos
aspectos que guardan relacin con IPv6, como por ejemplo una URI para poder llamar
una direccin IPv6 a travs de http, y este es el aspecto que quisimos destacar en esta
captura. Prestad atencin a que en el campo Location, se est llamando una
direccin IPv6, que tal cual est definido al invocar la versin 6, su direccin debe
quedar entre [ ], en esta captura http://[fe80::9d1]:2869/.



IP versin 6 (Parte 02) - Direccionamiento.

Madrid, abril de 2013.

1. Presentacin.

Como hemos mencionado, la parte histrica de IPv6 ya la conocemos, por lo tanto en este
segundo artculo manteniendo el concepto, es que tomamos como punto de partida el
hecho de que ya todos sabemos que una direccin IPv6 tiene 128 bits, y que se la
representa bsicamente con 8 grupos de cuartetos hexadecimales, es decir 8 grupos de
16 bits.
La idea fundamental de este artculo est basada en nuestras races es decir un enfoque
desde el punto de vista de la seguridad. Nuestra experiencia sobre IPv4 nos demuestra
que al ver pasar una direccin IP, inmediatamente este slo valor nos debe proporcionar
una alto grado de informacin. Por ejemplo en IPv4: si es unicast, multicast, broadcast,
privada, pblica, propia o externa, de qu segmento; en muchos casos, si diseamos
adecuadamente nuestras redes, tambin nos puede orientar si se trata de un dispositivo
de red, de un servidor, de un router, switch, proxy, firewall, en qu segmento est, etc.
Segn esta idea, intentaremos presentar el esquema de direccionamiento de IPv6 para que
al mirar una direccin, inmediatamente podamos situarnos sobre qu es lo que estamos
analizando, por lo tanto este texto posiblemente sea diferente a otros que circulan por la
red, pues iremos profundizando siempre sobre esta visin.

2. Introduccin.

El desarrollo se basar en una serie de RFCs, que son las siguientes:
rfc2464 Transmission of IPv6 Packets over Ethernet Networks
rfc2526 Reserved IPv6 Subnet Anycast Addresses
rfc3068 An Anycast Prefix for 6to4 Relay Routers
rfc3306 Unicast-Prefix-based IPv6 Multicast Addresses
rfc3307 Allocation Guidelines for IPv6 Multicast Addresses
rfc3587 IPv6 Global Unicast Address Format
rfc3956 Embedding the Rendezvous Point (RP) Address
rfc4007 IPv6 Scoped Address Architecture

rfc4193 Unique Local IPv6 Unicast Addresses

rfc4291 IP Version 6 Addressing Architecture
rfc4429 Optimistic Duplicate Address Detection (DAD) for IPv6
rfc 5952 A Recommendation for IPv6 Address Text Representation
rfc 6052 IPv6 Addressing of IPv4_IPv6 Translators
rfc6085 Address Mapping of IPv6 Multicast Packets on Ethernet
rfc6177 IPv6 Address Assignment to End Sites
rfc6620 FCFS SAVI- First-Come, First-Served Source Address Validation
rfc6724 Default Address Selection for Internet Protocol Version 6 (IPv6)

Algunas de las primeras son actualizadas por las ms recientes, e inclusive hay alguna que
otra que ya est obsoleta, aspectos que iremos describiendo en el texto.

3. Desarrollo.

3.1. La RFC 4291 IP Version 6 Addressing Architecture.

Comenzaremos presentando el tema con esta RFC de febrero de 2006 (deja obsoleta la
RFC-3513), pues como su nombre lo indica es la que mejor nos puede describir esta
arquitectura.

Uno de los primeros conceptos que nos da es que una direccin IPv6 se refiere
SIEMPRE a una interfaz (no a un nodo). Toda interfaz debe tener al menos una
direccin de "enlace local Unicast".

En el punto 2.2. Text Representation of Addresses describe que hay tres formas de
representar una IPv6

La forma preferencial es x:x:x:x:x:x:x:x, y pone los siguientes ejemplos:

ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
2001:DB8:0:0:8:800:200C:417A

Debido a que ciertos tipos de direccionamiento IPv6 presentarn cadenas
de ceros, los mismos pueden ser comprimidos u obviados con una doble
puntuacin del tipo "::" y aporta los siguientes ejemplos:

2001:DB8:0:0:8:800:200C:417A (direccin Unicast)
FF01:0:0:0:0:0:0:101 (direccin Multicast)
0:0:0:0:0:0:0:1 (Direccin de Loopback)

0:0:0:0:0:0:0:0 (Direccin no especificada)

Las anteriores pueden ser representadas como figura a continuacin:

2001:DB8::8:800:200C:417A
FF01::101
::1
::

Una forma alternativa que puede ser ms conveniente cuando nos
encontramos en un entorno mixto (IPv4 e IPv6) es de la forma
x:x:x:x:x:x:d.d.d.d Los ejemplos que propone son:

0:0:0:0:0:0:13.1.68.3 (o comprimido ::13.1.68.3)
0:0:0:0:0:FFFF:129.144.52.38 3 (o comprimido ::FFFF:129.144.52.38)

El punto 3. Text Representation of Address Prefixes de esta RFC nos hace referencia
que una IPv6 mantiene la idea de CIDR (Classless Inter-Domain Routing) de forma
similar a IPv4 (es decir como una mscara de red/subred) y cita como ejemplos:

2001:0DB8:0000:CD30:0000:0000:0000:0000/60
2001:0DB8::CD30:0:0:0:0/60
2001:0DB8:0:CD30::/60

El punto 2.4. Address Type Identification nos describe cmo las direcciones IPv6 se
identifican por los bits de ms alto orden (es decir los de ms a la izquierda),
presentando las siguientes direcciones:

Address type Binary prefix IPv6 notation Section
------------ ------------- ------------- -------
Unspecified 00...0 (128 bits) ::/128 2.5.2
Loopback 00...1 (128 bits) ::1/128 2.5.3
Multicast 11111111 FF00::/8 2.7
Link-Local unicast 1111111010 FE80::/10 2.5.6
Global Unicast (Todo lo dems)
(Cada uno de estos Tipos de direccionamiento los iremos desarrollando en el texto).

NOTA: Sobre este punto de la RFC tenemos una objecin
que desarrollaremos al final de esta seccin (*) .

Un aspecto a destacar es este nuevo esquema de direccionamiento Anycast (que
desarrollaremos ms abajo) y que no se trata de un rango especfico sino que se toma
de cualquier espacio Unicast y sintcticamente tampoco se distingue del formato
Unicast.

El punto 2.5. Direccionamiento Unicast de esta RFC, es por donde empezaremos a
tratar ms en detalle cada uno de ellos.

Hay varios tipos de direccionamiento Unicast, en PARTICULAR:

Unicast Global (posee algunos "Sub" tipos para propsitos especiales)
Unicast Site-local (quedara obsoleto segn el punto 2.5.7. de esta RFC)
Unicast Link-local

Vamos a presentar el formato de una direccin de la siguiente forma:

| n bits | 128-n bits |
+-------------------------------+---------------------------------+
| subnet prefix | interface ID |
+-------------------------------+---------------------------------+

Para TODAS las direcciones Unicast (excepto las que comienzan con los tres primeros
bits 000 la interface ID debe tener 64 bits de longitud y construida en formato
EUI-64 Modificado (que se tratar ms adelante, en la seccin 3.7.)
Los puntos que siguen van presentando el detalle, el 2.5.1. Interface Identifiers nos
aclara que un Identificador de interface especifica (o debera identificar)
unvocamente una interface sobre un enlace.

El punto 2.5.2. The Unspecified Address declara que la direccin 0:0:0:0:0:0:0:0 es
llamada direccin NO especificada y NUNCA debe ser asignada a un nodo.

El punto 2.5.3. The Loopback Address define el Unicast de la interfaz de loopback
0:0:0:0:0:0:0:1.

El punto 2.5.4. Global Unicast Addresses (que como se present en el punto 2.4 son
todas las dems) especifica el formato general de las direcciones de Unicast Global,
cuyo formato general es el siguiente:

| n bits | m bits | 128-n-m bits |
+------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID |
+------------------------+-----------+----------------------------+

Por ahora nos quedaremos con esta idea de todas las dems para que luego que
avancemos un poco ms podamos ver el detalle.

El punto 2.5.5.1. IPv4-Compatible IPv6 Address nos describe cmo se Compatibiliza
una IPv4 sobre una IPv6 cuyo formato es el siguiente:

| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|0000| IPv4 address |
+--------------------------------------+----+---------------------+
Este esquema est propuesto para su obsolescencia pues no se hace uso de esta
metodologa.


El punto 2.5.5.2. IPv4-Mapped IPv6 Address es el que s se est empleando para

mapear IPv4 existentes en despliegues de IPv6 y su formato es el que se presenta a
continuacin:

| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|FFFF| IPv4 address |
+--------------------------------------+----+---------------------+
Como podemos ver la diferencia son los 16 bits previos a la IPv4 que en este caso son
FFFF, el detalle de este esquema de mapeo se desarrolla en la RFC-4038
Application Aspects of IPv6 Transition.

Por ltimo el punto 2.5.6. Link-Local IPv6 Unicast Addresses nos relata cmo se debe
emplear el direccionamiento Unicast para Enlaces Locales (Link-Local) o sobre un
enlace simple. Estas direcciones tienen el siguiente formato:
| 10 bits | 54 bits | 64 bits |

+----------+-------------------------+----------------------------+
|1111111010| 0 | interface ID |
+----------+-------------------------+----------------------------+

Como podemos apreciar, se distinguen por sus primeros bits 1111 1110 10 que en
hexadecimal est definido como FE80. Este tipo de direcciones para nosotros sern
muy importantes, pues son las que emplearemos de forma Local y la RFC es muy
clara respecto a que los routers NO DEBEN encaminar (o enrutar) los paquetes
que contengan estas direcciones origen o destino hacia otros enlaces. Es decir
que justamente este rango de direcciones sern las que reemplazan los rangos de IPv4
Privadas (10.x.x.x/8, 172.16-31.x.x/16 y 192.168.x.x/24). Podemos considerar
tambin como Locales a otro rango FC00::/7 prefix to identify Local IPv6 unicast
addresses, que desarrolla la RFC-4193 y es justamente el motivo de esa NOTA que
mencionamos unos prrafos antes, reiteramos que se desarrollar aqu al final (*).
.

REFLEXIN: uno de los fundamentos de IPv6 es dejar de hacer uso de NAT,

por lo tanto la idea de Direcciones pblicas y privadas pierde mucho

sentido.

Hoy en da el direccionamiento privado es uno de los pilares de la
seguridad de una red.. Qu suceder con IPv6?

(lo desarrollaremos cuando comencemos con los artculos de seguridad en IPv6)

Sobre el punto 2.5.7. Site-Local IPv6 Unicast Addresses no nos detendremos pues esta
RFC aclara que no debe ser soportado por nuevas implementaciones, as que no
merece la pena dedicarle tiempo. Son las que estaban definidas por los 10 primeros
bits 1111 1110 11 (en hexadecimal FEC0h).

El punto 2.6. Anycast Addresses nos comenta que este tipo de direcciones son
asignadas a ms de una interfaz con la propiedad que un paquete enviado a esas
direcciones es enrutado a la interfaz mas cercana bajo los parmetros de distancia
que emplean los protocolos de enrutado (es decir que no se refiere a distancia fsica).

Como ya hemos mencionado su rango est dentro del de Unicast y sintcticamente es

indistinguible del mismo, se trata de una metodologa de configuracin explcita de
cada nodo, estas direcciones deben ser mantenidas como una entrada separada en los
sistemas (tablas) de enrutado

Lo que s nos describe como Predefinido es el formato de una direccin para Subred
de routers con la siguiente estructura:

| n bits | 128-n bits |
+------------------------------------------------+----------------+
| subnet prefix | 00000000000000 |
+------------------------------------------------+----------------+
El prefijo de esta subred (Subnet prefix) ser el que identifique a un enlace especfico,
es decir el mismo de todas las direcciones Unicast de ese enlace, y dejando a cero
todos los bits de identificador de esa Interface. Los paquetes que contengan esa
direccin destino, sern entregados a un router de esa Subred (Subred de routers),
en la cual todos sus routers debern estar configurados para soportar este rango de
Anycast, para las subredes sobre las que tengan interfaces y ser su responsabilidad
entregarlo al conjunto de routers que forman parte de esta Subred anycast.

El punto 2.7. Multicast Addresses de esta misma RFC nos habla de Multicast
(recordemos que ya no existe ms el concepto de Broadcast, por lo tanto debe
suplirlo justamente este punto).
Lo primero que nos presenta es su formato:

| 8 | 4 | 4 | 112 bits |
+------ -+----+----+---------------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------------+

Como podemos apreciar sus primeros bits son 11111111 que en hexadecimal
equivale a FFh esto identifica unvocamente que se trata de Multicast. Luego de ello
vemos dos cuartetos: flag y scop que si bien los describe con todo detalle este punto,
nosotros los desarrollaremos en los prximos puntos, para ir aclarando por partes.

Por ltimo el punto 2.8. A Node's Required Addresses nos explica todas las
direcciones que debe reconocer cualquier nodo que opere bajo IPv6, este aspecto no
difiere de IPv4 excepto en el tema de Anycast.

Como cierre de esta parte, nos interesa destacar que en el punto 4. IANA
Considerations aclara que IPv4 compatible con IPv6 (que presentamos ms arriba en
el punto 2.5.5.1.) queda obsoleto en esta RFC y que IANA debera continuar con el
esquema de direccionamiento en la URL:

http://www.iana.org/assignments/ipv6-address-space (Tema con el que
continuaremos en el siguiente punto).


(*) Volvamos a la NOTA: explicando esta objecin que tenemos sobre la RFC-4291.

En el punto 2.4. de la RFC-4291 "Address Type Identification" presentamos:

----------- ------------- ------------- -------
Loopback 00...1 (128 bits) ::1/128 2.5.3
Multicast 11111111 FF00::/8 2.7
Global Unicast (everything else)

Al final del mismo hace referencia a "Global Unicast (everything else)" esto en
realidad puede no ser as, pues la RFC-4193 "Unique Local IPv6 Unicast
Addresses" en su punto 1. "Introduction" dice textualmente:

This document defines an IPv6 unicast address format that is globally
unique and is intended for local communications [IPV6]. These addresses are
called Unique Local IPv6 Unicast Addresses and are abbreviated in this
document as Local IPv6 addresses. They are not expected to be routable
on the global Internet. They are routable inside of a more limited area such
as a site. They may also be routed between a limited set of sites.

(Es decir, al menos debera tratarse como un "caso especial" dentro del Unicast
Global, pues no es enrutable Globalmente) Por qu se hace tanta diferencia con
FE80::/10? (Si su lgica es muy similar).

Esta RFC (4193) En su punto 3. "Local IPv6 Unicast Addresses", punto 3.1.
"Format" presenta su formato:

| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+------------+-----------+----------------------------+
Donde:
Prefix FC00::/7 prefix to identify Local IPv6 unicast addresses.

A su vez IANA (http://www.iana.org/assignments/ipv6-address-space/ipv6-address-
space.xml) tambin lo reconoce y registra como:

2000::/3 Global Unicast
fe80::/10 Link-Scoped Unicast[RFC4291
fc00::/7 Unique Local Unicast [RFC4193]
(es decir nuevamente genera confusin pues figura como "Local" no "Global")

SOLUCIN PROPUESTA:

Si en la RFC 4291 en el punto 2.4. "Address Type Identification" se agregara la
lnea:
Site-local unicast 1111101 FC00::/7 (como un "caso especial")

Este punto quedara:

------------ ------------- ------------- -------
Loopback 00...1 (128 bits) ::1/128 2.5.3
Multicast 11111111 FF00::/8 2.7
Site-local unicast 1111101 FC00::/7
Global Unicast (everything else)

Y todo resultara ms claro. Tal vez pueda parecer un detalle sin importancia,
pero al tratar de entender o explicar estas RFCs, se dificulta mucho el tema pues
aparece un rango de direcciones IPs que no est claro (no forma, o no debera
formar, parte de "everything else") y llegar a una conclusin acertada se
complica.

Este rango FC00::/7 lo desarrollaremos en el punto 3.6. FC00::/7

3.2. Anlisis de los primeros 16 bits.

En nuestra opinin estos dos primeros octetos son los que nos dan la visin preliminar
de lo que estamos mirando.
Como acabamos de comentar la RFC-4291 en el punto 4. IANA Considerations, nos
hace referencia a la URL:
http://www.iana.org/assignments/ipv6-address-space
La tabla que nos presenta all a mediados de abril de 2013 es la siguiente:
IPv6 Prefix Allocation Reference Notes

0000::/8 Reserved [RFC4291] [1] [2] [3] [4] [5]
by IETF
0100::/8 Reserved [RFC4291] 0100::/64 reserved for Discard-Only Address Block [RFC6666].
by IETF Complete registration details are found in [IANA registry iana-
ipv6-special-registry].
0200::/7 Reserved [RFC4048] Deprecated as of December 2004 [RFC4048]. Formerly an
by IETF OSI NSAP-mapped prefix set [RFC4548].
0400::/6, 0800::/5, Reserved [RFC4291]
1000::/4 by IETF
2000::/3 Global [RFC4291] The IPv6 Unicast space encompasses the entire IPv6 address
Unicast range with the exception of ff00::/8, per [RFC4291]. IANA
unicast address assignments are currently limited to the IPv6
unicast address range of 2000::/3. IANA assignments from this
block are registered in [IANA registry ipv6-unicast-address-
assignments]. [6] [7] [8] [9] [10] [11]
4000::/3, 6000::/3, Reserved [RFC4291]
8000::/3, a000::/3, by IETF
c000::/3, e000::/4, f800::/6
fc00::/7 Unique [RFC4193] For complete registration details, see [IANA registry iana-ipv6-
Local special-registry].
Unicast

fe00::/9 Reserved [RFC4291]

by IETF
fe80::/10 Link- [RFC4291] Reserved by protocol. For authoritative registration, see [IANA
Scoped registry iana-ipv6-special-registry].
Unicast
fec0::/10 Reserved [RFC3879] Deprecated by [RFC3879] in September 2004. Formerly a
by IETF Site-Local scoped address prefix.
ff00::/8 Multicast [RFC4291] IANA assignments from this block are registered in [IANA
registry ipv6-multicast-addresses].

[1] ::1/128 reserved for Loopback Address [RFC4291]. Reserved by protocol.
[2] ::/128 reserved for Unspecified Address [RFC4291]. Reserved by protocol.
[3] ::ffff:0:0/96 reserved for IPv4-mapped Address [RFC4291]. Reserved by protocol.
[4] 0000::/96 deprecated by [RFC4291]. Formerly defined as the "IPv4-compatible IPv6
address" prefix.
[5] The "Well Known Prefix" 64:ff9b::/96 is used in an algorithmic mapping between IPv4 to
IPv6 addresses [RFC6052].
[6] 2001:0000::/23 reserved for IETF Protocol Assignments [RFC2928].
[7] 2001:0000::/32 reserved for TEREDO [RFC4380].
[8] 2001:0002::/48 reserved for Benchmarking [RFC5180].
[9] 2001:db8::/32 reserved for Documentation [RFC3849].
[10] 2001:10::/28 reserved for ORCHID [RFC4843].
[11] 2002::/16 reserved for 6to4 [RFC3056].

Primer resumen: De todo esto Con qu interesa quedarnos por ahora?
Hemos resaltado en negrita sobre lo que centraremos nuestra atencin:
0000::1/8: Direccin de Loopback (como su anterior: 127.0.0.1).
0000::ffff:0:0/96: Reservado para mapear IPv4 en IPv6
0100::/8: RFC-6666 A Discard Prefix for IPv6 (Este lo hemos dejado pues
est diseado para filtrado de listas negras e invitamos a que le deis una
mirada a esa RFC)
2000::/3: Nos lleva a IANA registry ipv6-unicast-address-assignments
(http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-
assignments.xml) Lo tratamos en el punto 3.3.
fe80::/10 Nos lleva a IANA registry iana-ipv6-special-registry

(http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml) Lo
tratamos en el punto 3.4.
ff00::/8 Nos lleva a [IANA registry ipv6-multicast-addresses]
(http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml) Lo
tratamos en el punto 3.5.
fc00::/7 Nos lleva a [IANA registry ipv6-multicast-addresses]
(http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml) [RFC-
4193]. Lo tratamos en el punto 3.6.


Es decir por ahora, si analizamos una direccin IPv6 segn sus primeros bits,
podremos encontrar lo que hemos destacado en negrita en el prrafo anterior.

3.3. Global Unicast

2000::/3: Nos lleva a IANA registry ipv6-unicast-address-assignments
(http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml)

Si consultamos el enlace, la actual asignacin de direcciones es la que se presenta aqu
abajo:
Prefix Design. Date Whois Status Note
2001:0000::/23 IANA 1999-07-01 whois.iana.org ALLOC [RFC2928]. 2001:0000::/32 is reserved

for TEREDO [RFC4380]. 2001:0002::/48
is reserved for Benchmarking
[RFC5180]. 2001:10::/28 is reserved for
ORCHID [RFC4843].
2001:0200::/23 APNIC 1999-07-01 whois.apnic.net ALLOC
2001:0400::/23 ARIN 1999-07-01 whois.arin.net ALLOC

2001:0600::/23 RIPE NCC 1999-07-01 whois.ripe.net ALLOC
2001:0a00::/23 RIPE NCC 2002-11-02 whois.ripe.net ALLOC
2001:0c00::/23 APNIC 2002-05-02 whois.apnic.net ALLOC 2001:db8::/32 reserved [RFC3849]. see
[IANA registry iana-ipv6-special-registry].
2001:0e00::/23 APNIC 2003-01-01 whois.apnic.net ALLOC
2001:1200::/23 LACNIC 2002-11-01 whois.lacnic.net ALLOC
2001:1c00::/22 RIPE NCC 2001-05-04 whois.ripe.net ALLOC
2001:3c00::/22 IANA RES 2001:3c00::/22 is reserved for possible
future allocation to the RIPE NCC.
2001:4200::/23 AFRINIC 2004-06-01 whois.afrinic.net ALLOC
2001:4c00::/23 RIPE NCC 2004-12-17 whois.ripe.net ALLOC
2001:a000::/20 APNIC 2004-11-30 whois.apnic.net ALLOC
2001:b000::/20 APNIC 2006-03-08 whois.apnic.net ALLOC
2002:0000::/16 6to4 2001-02-01 ALLOC 2002::/16 reserved for 6to4 [RFC3056].


2800:0000::/12 LACNIC 2006-10-03 whois.lacnic.net ALLOC .
2a00:0000::/12 RIPE NCC 2006-10-03 whois.ripe.net ALLOC
2c00:0000::/12 AFRINIC 2006-10-03 whois.afrinic.net ALLOC
2d00:0000::/8 IANA 1999-07-01 RES
2e00:0000::/7 IANA 1999-07-01 RES
3000:0000::/4 IANA 1999-07-01 RES
3ffe::/16 IANA 2008-04 RES [RFC4380]. [RFC5156]
5f00::/8 IANA 2008-04 RES [RFC5156]

Qu es lo que implica esta asignacin? pues hasta ahora habamos visto que las
Direcciones Globales de Unicast (Global Unicast) eran todas las dems" (con la
excepcin expuesta de fc00::/7). Para aclarar este detalle es que hemos dejado la
tabla original, y sobre la misma vamos a prestar atencin a la ltima columna note.
En la primera casilla de la misma, podemos ver que se hace mencin a la RFC-2928, si
estudiamos esta recomendacin de septiembre del 2000, vemos que lo primero a lo
que hace referencia en su introduccin es el concepto de TLA (Top Level Aggregation)
relacionando el mismo a la RFC-2450 "Proposed TLA and NLA Assignment Rules". En
el punto 5.1. Proposed TLA Allocation Stages (de esta ltima) nos presenta el formato
del mismo y aclara que estar compuesto por los siguientes campos:
| 3 | 13 | 13 | 19 |
+----+----------+---------+---------------+
| FP | TLA | Sub-TLA | NLA |
| | ID | | ID |
+----+----------+---------+---------------+

Donde designa FP = 001 = Format Prefix.

Y aclara Textualmente: Este es el formato de prefijo usado para identificar la tabla de
agregacin global (es decir Mundial) de direcciones Unicast.
Luego presenta y asigna el TLA ID = 0x001 = Top-Level Aggregation Identifier.
Por ltimo en el punto 5.2. Proposed Assignment Requirements nos presenta los
conceptos de Sub-TLA, al final de esta recomendacin describe que los NLA ID (Next-
Level Aggregation ID) sern usados por las Organizaciones para crear la Jerarqua e
identificacin de sitios.
Por lo tanto hasta ahora podemos entender que los 16 primeros bits (3 FP + 13 TLA
ID) estn registrados como:
001 y 0xxxxxxxxx001 = 0010 xxxx xxxx x001 (quedmonos con esta idea).
No merece la pena detenernos ms en la RFC-2450 pues nuestro objetivo es entender
por qu no aparecen todos los dems?, por lo tanto ahora que comenzamos a
seguirle el rastro a este formato de Global Unicast mejor ser que volvamos a la RFC-
2928 que es la que dio origen a la tabla de asignacin que presentamos en este punto.

Esta RFC nuevamente nos presenta los primeros tres bits 001 de Formato de Prefijo
(FP) que acabamos de ver, tambin los siguientes trece de TLD ID 0xxxxxxxxx001 , y
sustentada por la RFC anterior contina ahora con lo trece siguientes registrando las
asignaciones iniciales del Sub-Top Level Aggregation Identifiers (Sub-TLA ID)
donde ahora s por primera vez encontramos lo siguiente:
Binary Value IPv6 Prefix Range Assignment
---------------- ------------------------------- -------------------
0000 000X XXXX X 2001:0000::/29 - 2001:01F8::/29 IANA
0000 001X XXXX X 2001:0200::/29 - 2001:03F8::/29 APNIC
0000 010X XXXX X 2001:0400::/29 - 2001:05F8::/29 ARIN
0000 011X XXXX X 2001:0600::/29 - 2001:07F8::/29 RIPE NCC
0000 100X XXXX X 2001:0800::/29 - 2001:09F8::/29 (future assignment)
0000 101X XXXX X 2001:0A00::/29 - 2001:0BF8::/29 (future assignment)
0000 110X XXXX X 2001:0C00::/29 - 2001:0DF8::/29 (future assignment)
0000 111X XXXX X 2001:0E00::/29 - 2001:0FF8::/29 (future assignment)
0001 000X XXXX X 2001:1000::/29 - 2001:11F8::/29 (future assignment)
. . . . . . . . .
1111 111X XXXX X 2001:FE00::/29 - 2001:FFF8::/29 (future assignment)
donde "X" indica "0" o "1"

Analicemos, por ejemplo, la primera lnea de estas asignaciones:
0000 000X XXXX X 2001:0000::/29 - 2001:01F8::/29 IANA
Lo que estamos viendo aqu al principio (0000 000X XXXX X) son los trece primeros bits
del Sub-TLA, los cules estarn precedidos por los 16 primeros bits (3 FP + 13 TLA
ID) que como acabamos de ver son 0010 xxxx xxxx x001, el primer rango de todas
esas x sern a 0 y en consecuencia esa primera lnea quedar:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 Bits
FP TLA ID SubTLA ID Nombre
0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 x x x x x x Rango (b)
0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 Inicio (b)
2 0 0 1 0 0 0 0 Inicio (h)
0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 1 1 1 1 Fin (b)
2 0 0 1 0 1 F 8 Fin (h)

Por lo tanto, para cerrar este punto, lo que podemos afirmar sin lugar a dudas es que
de todas las dems direcciones IPv6 que se corresponden al Unicast Global (es decir
las que viajarn de un extremo al otro de Internet, hoy abril del 2013, las nicas que
estn registradas por IANA son las que comienzan con 0010(b) = 2(h) (pues
inclusive las 3 si miramos la tabla anterior, se encuentran RESERVADAS pero an
no asignadas: ALLOC).
CONCLUSIN importante: Cuando vemos una IPv6 que comienza por 2
(h) sin lugar a dudas es GLOBAL (es decir enrutable por todo Internet).
No seguiremos avanzando ms sobre este rango de direccionamiento, pero si alguien
lo desea puede volver a la tabla con que iniciamos este punto y seguir con la secuencia
de asignaciones que fue evolucionando en cada una de las zonas de Internet (RIPE,
ARIN, LACNIC, APNIC, AFRNIC) partiendo de esta tabla podemos observar y
profundizar todo lo que se desee.

3.4. Link Local

fe80::/10 IANA registry iana-ipv6-special-registry file://localhost/(http/::www.iana.org:assignments:iana-ipv6-
special-registry:iana-ipv6-special-registry.xml)
Si consultamos este enlace, la actual asignacin de direcciones es la que se presenta

aqu abajo:

Address Allocation Desti Forwar Reserved-by-
Name RFC Source Global
Block Date nation dable Protocol
::1/128 Loopback Address
[RFC4291] February False False False False True
2006
::/128 Unspecified Address [RFC4291] February True False False False True
2006
::ffff:0:0/96 IPv4-mapped [RFC4291] February False False False False True
Address 2006
64:ff9b::/96 IPv4-IPv6 Translat. [RFC6052] October 2010 True True True True False
100::/64 Discard-Only [RFC6666] June 2012 True True True False False
Address Block
2001::/23 IETF Protocol [RFC2928] September False[1] False[1] False[1] False[1] False
Assignments 2000
2001::/32 TEREDO [RFC4380] January 2006 True True True False False
2001:2::/48 Benchmarking [RFC5180] April 2008 True True True False False
2001:db8::/32 Documentation [RFC3849] July 2004 False False False False False
2001:10::/28 ORCHID [RFC4843] March 2007 False False False False False
2002::/16[2] 6to4 [RFC3056] February True True True N/A[2] False
2001
fc00::/7 Unique-Local [RFC4193] October 2005 True True True False False
fe80::/10 Linked-Scoped [RFC4291] February True True False False True
Unicast 2006

Como podemos apreciar, nuevamente nos dirige hacia la RFC-4291. Ya hemos tratado
prcticamente todo los aspectos que desarrolla esta RFC en el punto 2.5.6. Link-Local
IPv6 Unicast Addresses (en realidad, le dedica menos de diez renglones), lo que s
creemos adecuado es agregar un par de reflexiones adicionales.
En general siendo estricto en la jerga de los modelos de capas, cuando aparece la
palabra Link (enlace) guarda estrecha relacin justamente con esta capa o nivel (la
capa 2). En este caso particular tiene ms sentido an, pues tal cual mencionamos, este
rango de direcciones est remarcado porque ningn router encaminar., es decir lo
que est proponiendo la RFC-4291 sobre las direcciones fe80 es que se queden en un
nivel de Enlace y justamente as las llama Link Local (enlace local) y tal vez esta
sea su ms clara expresin, con ello encontramos sentido a diferenciarlas claramente
con ese otro rango especial fc00 que lo llama Site-Local y este s que nos propone
para unir diferentes sitios, redes, rutas.
Otro aspecto que deseamos profundizar est relacionado con la totalidad de
direcciones que este rango ocupa, pues si bien estamos considerando fe80, la
realidad es que el rango es fe80::/10, es decir mscara 10 y con ello el rango
completo abarca lo siguiente:


Son RED NO son RED

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Bits
1 1 1 1 1 1 1 0 1 0 0 0 0 0 0 0 Inicio (b)
F E 8 0 00.0 Inicio (h)
1 1 1 1 1 1 1 0 1 0 1 1 1 1 1 1 11..1 Fin (b)
F E B F 11..1 Fin (h)

Por lo tanto, cuando analizamos este rango de IPv6 de Enlace Local, podemos
encontrarnos, no slo con direcciones que comiencen con FE80 sino tambin con
FEBF y cualquiera de sus valores intermedios (FE9x y FEAx).

3.5. Multicast

Como hemos mencionado, este rango queda unvocamente identificado por su primer
octeto FF o 1111 1111 en binario, la URL donde se puede obtener informacin
sobre los registros es: ff00::/8 [IANA registry ipv6-multicast-addresses]. El cuadro bsico de
asignacin de las mismas es el que figura a continuacin:

Date
Address(s) Description Reference Last Reviewed
Registered
FF01:0:0:0:0:0:0:1 All Nodes Address [RFC4291]
FF01:0:0:0:0:0:0:2 All Routers Address [RFC4291]
FF01:0:0:0:0:0:0:FB mDNSv6 [RFC6762] 2005-10-05

Luego presenta ms detalle sobre otros registros que amplan esta tabla, los mismos
estn en:
Registries included below
Node-Local Scope Multicast Addresses
Link-Local Scope Multicast Addresses
Site-Local Scope Multicast Addresses
Variable Scope Multicast Addresses
Source-Specific Multicast block
No ampliaremos ms sobre estos registros para poder centrarnos en lo que s nos

interesa, si alguien desea profundizar en ellos queda el hipervnculo a cada uno de los
mismos.
Lo que nos interesa es avanzar sobre lo que la RFC-4291 describe en su punto 2.7
Multicast Address
Al principio, cuando presentamos esta RFC lo hicimos a travs de sus primeros octetos,
aclaramos lo de 1111 1111 y dejamos pendiente que luego de ello vemos dos
cuartetos: flag y scop con los que seguiremos ahora:
Este primer cuarteto Flag est definido con cuatro bits cuyo significado es

+-+-+-+-+
|0|R|P|T|
+-+-+-+-+

Donde:
T = 0 indica que se trata de uno de los valores Permanentemente asignados
o Registrados (es decir los que figuran en las tablas con que iniciamos este
punto). Los llama Well-known (bien conocido) al igual que los puertos
TCP/UDP por debajo de 1024 o las direcciones IP, etc. Implica que se trata de
un valor que no puede ser empleado para otro fin diferente al que figura en ese
registro.
Si T = 1 indica que no es permanente, lo define como transitorio o
Dinmicamente asignado.
P: Se define en la RFC-3306.
Esta RFC-3306 es un documento muy breve que nos describe cmo poder hacer
una asignacin dinmica de Multicast, se basa en el empleo de este tercer bit
del Flag, el bit P (por Prefix) y en definitiva lo que indica este bit es que:
P = 0 esta direccin de multicast no est basada en el Prefijo de red
(es decir, los tres primeros bits de los 128 de este rango de direcciones
IP).
P = 1 S est basada en este Prefijo de red
Y aclara un tema ms: Si P = 1 T tambin DEBE ser = 1.
Define algunos aspecto ms que no merece la pena desarrollar en este texto.

R: Se define en la RFC-3956
La RFC-3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast
Address (que actualiza a la RFC-3306), define el empleo de este bit justamente
para permitir un mecanismo escalable de multicast inter a intra dominios a
travs de este concepto de Punto de encuentro o punto de cita
(Rendezvous Point (RP) ). Esta s es una RFC ms compleja, de la que nos
interesa rescatar que a travs del empleo de este bit, es decir cuando R = 1, se
indica que un nuevo direccionamiento multicast, est embebido en este
esquema de direccionamiento; en esos casos define que los bits P y T
tambin DEBEN estar en 1. Cuando se cumple esta condicin, a partir del
cuarteto flag, comienza un formato diferente de direccionamiento que est
descrito por esta RFC.
No es objetivo de esta articulo llegar al nivel de detalle de esta RFC, solamente
desebamos comentar su empleo y funcin, y todo aquel que necesite
profundizar en este mecanismo puede hacerlo consultando esta
recomendacin.


En cuanto al segundo cuarteto Scop (scope) se emplea para limitar el mbito de

este grupo y la RFC define los siguientes valores:

0 reserved
1 Interface-Local scope
2 Link-Local scope
3 reserved
4 Admin-Local scope
5 Site-Local scope
6 y 7 (unassigned)
8 Organization-Local scope
9, A, B, C y D (unassigned)
E Global Scope
F reserved

El valor 1 es un concepto nuevo que se define para multicast, aplica a una sola
interfaz, recordemos como empezamos con esta RFC Una direccin IPv6 aplica
siempre a una interfaz (no a un nodo), bajo este concepto es que un mismo nodo
permite la opcin de tener n direcciones IP (an teniendo una sola interfaz fsica).
El valor 2 aplica al mismo mbito que acabamos de desarrollar de Link-Local
(enlace local); es decir, a todas las interfaces del rango FE80::/10.
El valor 3 Admin-Local, es el mbito ms pequeo que puede ser
administrativamente configurado, pone por ejemplo un mbito que no se derive de la
conectividad fsica u otros tipos de multicast que estn aqu desarrollados.
El valor 4 aplica a Site-Local y abarca una sola Site. Si lo pensamos en trminos de
FC00::/7, debera aplicar a uno solo delos rangos de todas las Sites que abarque
nuestra organizacin. En el caso de necesitar un multicast que aplique a toda la
Organizacin (a ms de una Site), es el valor 8 que se define para Organization-
local.
Por ltimo el valor E se emplea para todo Internet.
Estos valores de Scope, la RFC establece que son independientes del significado del
bit T (0: permanente o 1: temporal).

Para cerrar este punto la RFC-4291 pone como ejemplo el caso de un multicast ntp
(Network Time Protocol). Si miramos nuevamente la tabla de registros multicast con
la que iniciamos este punto, podemos ver que hay uno de estos registros que es:
Variable Scope Multicast Addresses
En esta tabla nos presenta justamente este multicast ntp

FF0X:0:0:0:0:0:0:101 Network Time Protocol (NTP) [RFC1119]
Los comentarios que hace sobre esta tabla son:

These permanently assigned multicast addresses are valid over all

scope ranges. This is shown by an "X" in the scope field of the
address that means any legal scope value.
Es decir, estamos viendo en este comentario la definicin de Permanente y de
Scope, pues nos aclara que se trata de asignacin permanente que es vlida para
cualquier mbito (scope), y esto es el ejemplo que propone la RFC y que explicamos a
continuacin:
Ejemplo: Si el grupo de servidores "NTP tiene asignado la direccin permanente:
101 (h) (tal cual vimos en la tabla anterior), entonces:
FF01:0:0:0:0:0:0:101 significa todos los servidores NTP sobre la misma Interfaz
del que enva. (scope 1 Interface-Local)
FF02:0:0:0:0:0:0:101 significa todos los servidores NTP sobre el mismo enlace
del que enva (scope 2 Link-Local)
FF05:0:0:0:0:0:0:101 significa todos los servidores NTP sobre la misma Site del
que enva (scope 5 Site-Local)
FF0E:0:0:0:0:0:0:101 significa todos los servidores NTP sobre Internet (scope
E Global).

3.6. FC00::/7.

Hasta ahora habamos presentado en nuestra NOTA (en verde) que este rango al
menos debera ser tratado como un caso especial, comentamos que hay un registro
particular definido en IANA [IANA registry ipv6-multicast-addresses]
(http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml).
Que a su vez en (http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml)

IANA tambin lo reconoce y registra como:
2000::/3 Global Unicast
fe80::/10 Link-Scoped Unicast[RFC4291
fc00::/7 Unique Local Unicast [RFC4193]
("Local" no "Global")
Analicemos ahora con ms detalle la RFC-4193 Unique Local IPv6 Unicast Addresses
pues propone aspectos que deberamos conocer.
En su Introduccin comienza hablando que este documento define un formato de
direcciones unicast que es globalmente nico y se entiende para comunicaciones
locales, las mismas no son pensadas para ser enrutadas sobre Internet, sino dentro de
un rea limitada, como por ejemplos una Site pero s pueden ser enrutadas entre
un nmero limitado de Sites. Es decir estamos presentando claramente un
esquema de direccionamiento para comunicacin Intra o Inter Sites pero que no
diseado para navegar por Internet.

Contina definiendo una serie de caractersticas que a nuestro juicio son novedosas,
por ejemplo:
- Prefijo Globalmente nico (con alta probabilidad de Unicidad)
Esta caracterstica la hemos resaltado, no con la intencin de continuar nuestro debate
sobre si es local o global sino porque luego comienza a detallar que este mecanismo
permite comunicar estas diferentes Sites, con independencia del proveedor de
Internet, sin necesidad de re-numeraciones de direccionamientos locales e inclusive
hace referencia en que si accidentalmente se filtrara una de estas direcciones (hacia
Internet) va rutas o DNSs, no habra conflicto con otras direcciones.

Hasta ahora esta RFC que suena bastante extraa, contina ms rara an cuando a
partir del punto 3.1. Format presenta otro formato para el direccionamiento usando
un mtodo de asignacin Pseudo random. Nos habla de una evaluacin de la
poblacin mundial para el ao 2050 de unos 9.300.000.000 de habitantes. Todo esto
avanza hacia una propuesta de clculo del campo Global ID (40 bits siguientes a los
8 de FC) que NO DEBE ser asignado de forma secuencial o con nmeros conocidos, y
con ello se asegurara que no exista relacin entre diferentes ubicaciones y ayude a
clarificar que cualquiera de estos valores no tengan ninguna lgica de enrutado a nivel
geogrfico o global, pasando luego directamente a la explicacin de este mtodo que
tiene una extremadamente alta probabilidad de ser nica.
Los pasos resumidamente son:
a. Obtener la fecha del da en 64 bits (formato NTP).
b. Obtener un identificador EUI-64 ejecutando este algoritmo.
c. Concatenar ambos
d. Ejecutar un resumen con la funcin SHA-1 (que es de 160 bits)
e. Usar los 40 bits menos significativos como Global ID.
f. Concatenar FC00::/7 con el octavo bit (que esta RFC lo define como L) puesto
a 1 con estos nuevos 40 bits obtenidos.
Basado en el clculo de probabilidades, en
la norma se calcula el valor de P como Conexiones Probabilidad de colisin
la probabilidad de Colisin (que en 2 1,81 * 10-12
criptografa implica valores iguales), es 10 4,54 * 10-11
decir, la probabilidad que puedan 100 1,81 * 10-9
aparecer repetidos estos ID y el resultado 1.000 1,81 * 10-7
es el que se muestra en la tabla. 10.000 1,81 * 10-5
Por esta razn (o fortaleza ante
colisiones) es que remarca que se calcule de esta forma y no de otra. Al final de este
artculo veremos un ejercicio prctico de este caso.
En el punto 4.1. Routing aclara que este rango est designado para ser enrutado
dentro de una Site de la misma forma que cualquier otro tipo de direcciones Unicast,
y que la conducta normal de cualquier protocolo de enrutado exterior debera ser
ignorar y no advertir prefijos FC00::/ haciendo la salvedad que un operador podra

especficamente configurar prefijos de este tipo para comunicacin Inter Sites. En el

punto 4.3. Site Border Router and Firewall Packet Filtering tambin aclara que estos
dispositivos deberan ser configurados para filtrar o no enrutar estas direcciones, a
menos que hayan sido explcitamente configurados para ello, y lo mismo como ruta por
defecto. Deberan responder con un mensaje ICMPv6 informando que ese paquete no
ha sido enrutado (para evitar time out).

3.7. EUI-64 y el mapeo de IPv6 sobre Ethernet (para Unicast y Multicast)

En este apartado reuniremos estos dos conceptos que an tenemos pendientes, es
decir de qu se trata EUI-64 y como se entrega una paquete IPv6 al nivel 2 (enlace)
para que este lo transforme en una trama, en nuestro caso Ethernet (aunque tambin
estn definidos otros estndares de este nivel), y lo transmita por la red.

1) El formato EUI-64.

Hasta la llegada de IPv6 seguramente no habamos escuchado mucho sobre EUI-64
(aunque ya exista) pues lo ms probable es que llevramos aos trabajando con el
formato EUI-48, comnmente llamado direccionamiento MAC o MAC-48 (Para ms
detalle de este direccionamiento ver libro Seguridad por Niveles).
Las definiciones iniciales de este formato nacen con el estndar IEEE 802-2001
(Institute of Electrical ans Electronics Engineers); esta norma que fue reafirmada
en marzo de 2007, en su punto 9 desarrolla el concepto de direccionamiento
universal con todo el detalle terico y prctico. En cuanto a su implementacin, tal
vez es mejor tomar como referencia una Gua (de noviembre de 2012) tambin de
IEEE para el Identificador Global EUI-64 que podemos encontrar en:
http://standards.ieee.org/develop/regauth/tut/eui64.pdf, en ella se presenta el
empleo de este formato de direccionamiento para el nivel de enlace. Este breve
documento sencillamente nos lo describe como una concatenacin de 40 bits
adicionales a los 24 bits de OUI (Organizationally Unique Identifier), hace
referencia a los derechos reservados sobre este formato, y lo ms importante para
nuestro artculo es que al final de esta gua menciona que para IPv6 la derivacin
de este formato figura en el apndice A de la RFC-4291, as que volvamos
nuevamente a esta RFC.
Apndice A Creating Modified EUI-64 Format Interface Identifiers a la RFC-4291.
Aqu aparece por primera vez la palabra Modificado, y esto se debe a que lo
primero que nos aclara es que el nico cambio que se necesita para transformar un
IEEE EUI-64 a un identificador de interface Ipv6 es invertir el bit u
(universal/local). Vamos a recordar que los primeros bits de una direccin de este
tipo, son los que identifican unvocamente al fabricante de esa interfaz de red, pero
dentro de estos 24 bits, hay dos de ellos que tienen un significado especial
(nuevamente para profundizar sobre el tema, os invitamos a ver el libro

Seguridad por Niveles), se trata de los bits 7 y 8 del primer octeto que se
emplean para identificar si una direccin se corresponde a un enlace Universal o
Local y si es Grupal o Individual. En este caso, la RFC nos plantea el cambio del
bit 7 (Universal/Local) y presenta este formato:
|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 correspondientes justamente al fabricante, 0 es el valor del

bit Universal/Local, g es el bit de Individual/grupal y m son los bits que el
fabricante ha seleccionado como identificador de extensin.
Para una IPv6, el cambio de este bit, debera quedar entonces como:

|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
Donde se puede apreciar que el nico cambio ha sido la modificacin de 0 por 1

justamente en este bit (Universal/Local).
Luego de esta modificacin, este apndice describe cmo crear un EUI-64 desde
una direccin MAC definida por IEEE con 48 bits (es decir desde una EUI-48) y para
ello solamente se debe insertar los siguientes octetos hexadecimales FF y FE a
continuacin de los primeros 24 bits (es decir los correspondientes a OUI) y pone
los siguientes ejemplos:
A partir de una direccin EUI-48 (manteniendo la idea de los bis c, 0, g, m ).
|0 1|1 3|3 4|
|0 5|6 1|2 7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+

Se crea una direccin EUI-64 (agregando los dos octetos FF y FE que en binario
son 11111111 11111110):
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
Al final de este apndice agrega una nota que hace referencia a la propuesta inicial
de IEEE de emplear FF FF y que en implementaciones iniciales de IPv6 fueron
empleados, pero que a partir de este documento se recomienda el empleo de FF
FE pues esta ser la forma de identificar que se est trabajando con IPv6.


En el mes de septiembre de 2008, aparece una segunda RFC que vuelve a tratar
este tema de EUI-64 Modificado, se trata de la RFC-5342 IANA Considerations and
IETF Protocol Usage for IEEE 802 Parameters, en el punto 2.2.1. IPv6 Use of
Modified EUI-64 Identifiers, reitera el empleo de este formato EUI-64 Modificado y
lo relaciona al rango que se le asigna a IANA.

Como ejemplo prctico presentamos a continuacin una direccin real de IPv6
proveniente justamente de este mapeo de EUI-48 a EUi-64:
en0: <UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

ether 3c:07:54:6c:a2:29
inet6 fe80::3e07:54ff:fe6c:a229%en0 prefixlen 64 scopeid 0x4
Como podemos apreciar la direccin MAC es de formato EUI-48:

ether 3c:07:54:6c:a2:29
Al transformarse en una IPv6 estos mismos campos son ahora:

inet6 fe80::3e07:54ff:fe6c:a229
Se puede apreciar la insercin de los octetos ff y fe, pero a su vez hay otro aspecto
que merece la pena analizar, si prestamos atencin al primero octeto de la
direccin EUI-48 (ether) este es 3c, sin embargo al transformarse en EUI-64, este
pasa a ser 3e.???????? (es raro esto?), es lo que acabamos de presentar
del bit siete (Universal/Local), vamos a estudiarlo en binario:
1 2 3 4 5 6 7 8 Bits
3 C EUI-48 (h)
0 0 1 1 1 1 0 0 EUI-48 (b)
3 E EUI-64(h)
1 1 1 1 1 1 1 0 EUI-64 (b)
Como podemos ver, se trata justamente de este sptimo bit (Universal/Local), que
se ha cambiado de cero a uno, tal cual lo indica la RFC-4291.
Y los primeros dos octetos de esta direccin fe80, an recordamos de qu se
tratan?..........

2) Entrega al nivel 2.

Lo primero que debemos tener en cuenta sobre esta tarea es lo que desarrollamos
en el primer artculo IPv6 (Parte 01) Componentes es que para el formato de
las tramas Ethernet (protocolo que forma parte de los componentes de esta
nueva versin de IP), se ha definido un nuevo valor 86 en hexadecimal para
aplicar en su campo Ethertype con el objetivo de identificar como protocolo de
nivel superior a IPv6, por lo tanto este es el primer aspecto a considerar.
El segundo a destacar, es el caso de la Inter relacin que deben tener el nivel 2
con el 3 para el caso de Multicast, pues si IPv6 desea enviar un paquete a ms de
una direccin destino, debe informarle de alguna forma al nivel de enlace para que

este pueda poner sobre aviso a cualquier switch que esa trama debe reenviarla
por TODAS sus bocas. Esta actividad, para el caso de Ethernet, est definida en la
RFC-2464 IPv6 Packets over Ethernet. En el punto 7 Address Mapping
Multicast de la misma, como su nombre lo indica propone cmo hacerlo, se basa
en que la direccin destino EUI-48 de esa trama a enviar, se forme con el valor 33
33 (en hexadecimal) para sus dos primeros octetos, seguidos de los cuatro ltimos
de la direccin destino IPv6, lo que se ve ms claro con el ejemplo que all figura:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST[13] | DST[14] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST[15] | DST[16] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Como podemos ver en este ejemplo, la direccin EUI-48 queda formada por los dos
primeros octetos: 0011 0011 0011 0011 que es 33 33 en su representacin
binaria, seguidos de los octetos 13, 14, 15 y 16 (es decir los cuatro ltimos) de la
direccin destino IPv6.



En esta seccin presentaremos brevemente algunas capturas de trfico relacionadas a los
componentes que hemos descrito.

a. Ejemplo de Multicast
Como hemos presentado, una direccin Multicast IPv6 presenta varios aspectos que
podemos considerar, aqu abajo presentamos un ejemplo de la misma:

Lo primero que hemos destacado en rojo es justamente el valor 33 33 con que
comienza la direccin EUI-48 (direccin MAC) que fue el ltimo tema tratado en el
artculo, segn la RFC-2464 es la forma en que se mapea este concepto de Multicast
desde el nivel de red (IPv6) al nivel de enlace (Ethernet), para que cualquier switch
que reciba esta trama automticamente mire el bit correspondiente a
Individual/grupal (bit 8 del primer octeto) y sepa que se trata de un mensaje para ms
de una direccin destino y lo repita por TODAS sus bocas.
Lo segundo destacado es el valor 86 del campo Ethertype que tal cual se ve en la
imagen directamente lo asocia a IPv6 como protocolo de capa superior.
Por ltimo podemos ver la direccin destino IPv6, en la cual como hemos desarrollado
en el punto 3.5 Multicast apreciamos que comienza con FF, luego sigue con 02
donde podemos ver el valor de los cuartetos: Flag y Scope, en este caso:
- Flag: 0 bits: 0 - R - P T (todos cero)
R=0 No hay punto de encuentro (R: Rendezvous Point).
P =0 No est basada en el prefijo de red

T=0 Valor permanentemente asignado

- Scope: 2 = Link-Local scope (es decir, que este multicast aplica a todas las
interfaces del rango FE80::/10).
Por ltimo si volvemos a analizar el IPv6 Multicast Address Space Registry

Link-Local Scope Multicast Addresses
Address(s) Description Reference Date Reg. Last Rev.

FF02:0:0:0:0:0:0:1 All Nodes Address [RFC4291]
Podemos verificar que se tata de una direccin multicast, dirigida a todas los nodos de
este rango.

b. Empleo de Enlace Local, sin mapeo a IPv4

Dentro de las direcciones de Enlace Local (FE80::/10) presentamos que la RFC-4291
en el punto 2.5.5.2. IPv4-Mapped IPv6 Address describe que para mapear IPv4
existentes en despliegues de IPv6 se debe hacer uso de los octetos FFFF previo a los
cuatro de IPv4 y presentamos su formato:

| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|FFFF| IPv4 address |
+--------------------------------------+----+---------------------+
Luego en el punto 2.5.6. Link-Local IPv6 Unicast Addresses de la misma nos relataba
cmo se debe emplear el direccionamiento Unicast para Enlaces Locales (Link-
Local) o sobre un enlace simple empleando el siguiente formato:
| 10 bits | 54 bits | 64 bits |

+----------+-------------------------+----------------------------+
|1111111010| 0 | interface ID |
+----------+-------------------------+----------------------------+

En la primera captura que se ve a continuacin, se aprecia este ltimo caso:



Estamos viendo un enlace local (FE80) en el cual no se guarda ningn tipo de relacin
entre el direccionamiento MAC y el de IPv6. Tambin podemos verificar en esta
captura el formato que acabamos de presentar respecto al punto 2.5.6. Link-Local
IPv6 Unicast Addresses de la misma para Enlaces Locales:
| 10 bits | 54 bits | 64 bits |

+----------+-------------------------+----------------------------+
|1111111010| 0 | interface ID |
+----------+-------------------------+----------------------------+
Analicemos la direccin IPv6 destino:
fe80::69f6:7742:33cd:ebc3
Lo que se est presentando aqu es:
| 10 bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111010| 0 | interface ID |
+----------+-------------------------+----------------------------+
| f e 10|0000000 00000000| 69 f6 77 42 33 cd eb c3 |
+----------+-------------------------+----------------------------+
Para el caso de que s se guarde relacin entre la direccin MAC y la direccin IPv6, es
que hemos explicado que se crea una direccin EUI-64 (agregando los dos octetos FF y
FE que en binario son 11111111 11111110):
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
En la imagen de la captura que presentamos a continuacin, se puede apreciar este

caso.


Hemos subrayado ambas direcciones (MAC e IPv6), se puede apreciar que los seis
octetos del formato EUI-48, se transforman en EUI-64 insertando justamente ff fe
(que recuadramos en verde) y con estos 64 bits se forma la IPv6. Recordemos tambin
la Inversin del sptimo bit Local/universal que pasa de 0 a 1 tal cual se muestra
en el formato y en el caso de la captura, es justamente la diferencia en el primer octeto
MAC 3c (0011 1100) que luego se transforma en 3e (0011 1110).

c. Site Local (Fc00::/7):

Para poder esclarecer un poco ms este aspecto es que hemos generado los pasos que
indica la RFC-4193 en la creacin de estos para poder generar un poco de trfico, el
cual presentamos a continuacin.

En el punto 3.6 de nuestro artculo hicimos mencin a la importancia que esta
RFC le asigna a la generacin de este rango de direccionamiento (para evitar
colisiones), la misma en el punto 3.2.2. Sample Code for Pseudo-Random
Global ID Algorithm nos describe el procedimiento tal cual figura a
continuacin:
1) Obtain the current time of day in 64-bit NTP format [NTP].
2) Obtain an EUI-64 identifier from the system running this algorithm. If an EUI-64
does not exist, one can be created from a 48-bit MAC address as specified in
[ADDARCH]. If an EUI-64 cannot be obtained or created, a suitably unique
identifier, local to the node, should be used (e.g., system serial number).
3) Concatenate the time of day with the system-specific identifier in order to create a
key.
4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1]; the resulting
value is 160 bits.
5) Use the least significant 40 bits as the Global ID.
6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global ID to create a Local
IPv6 address prefix.

Ejercicio realizado (en un Mac, con sistema operativo Lyon, por lnea de comandos):

1) Obtain the current time of day in 64-bit NTP format [NTP].

Con el comando ntpq obtuvimos este valor: d 51a4f70630964e1

2) Obtain an EUI-64 identifier from the system running this algorithm.
Con el comando ifconfig:
sh-3.2# ifconfig en0
flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4>
ether 3c:07:54:6c:a2:29
inet6 fe80::3e07:54ff:fe6c:a229%en0 prefixlen 64 scopeid 0x4
inet 10.102.202.4 netmask 0xffffffc0 broadcast 10.102.202.63
media: autoselect (100baseTX <full-duplex>)
status: active
3) Concatenate the time of day with the system-specific identifier in order to create a
key.
d51a4f70630964e13c07546ca229

4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1]; the resulting
value is 160 bits.

ace$ echo -n "d51a4f70630964e13c07546ca229" | openssl sha1
(stdin)= cd7785eaca93e21be6675a18f1938fcaf8635229

5) Use the least significant 40 bits as the Global ID.
cd7785eaca

6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global ID to create a Local
IPv6 address prefix.
(Cuidado aqu) de FC00::/7 (Slo consideramos los primeros siete
bits): F(h) = 1111 (b), C(h) = 1100 (b), pero de aqu nos pide que el
sptimo bit L sea 1 => por lo tanto consideramos: 1111 1110 = fe
La Concatenacin entonces nos queda:
fecd:7785:eaca::/48
Sobre este rango configuramos manualmente dos dispositivos:
- router: f ecd:7785:eaca::1/48
- Porttil: f ecd:7785:eaca::2/48
Este es el trfico que se puede apreciar en la captura siguiente:

En la captura anterior podemos ver solicitudes y respuestas ICMPv6 entre ambas

direcciones IP.

d. Direccionamiento pblico (Global Unicast 2000::/3):

Cuando presentamos este tema en el punto 3.3. de esta artculo, desarrollamos todo
este rango, explicamos en detalle como se conforman estas direcciones y cerramos
esos prrafos con la siguiente CONCLUSIN importante:
Cuando vemos una IPv6 que comienza por 2 (h) sin
lugar a dudas es GLOBAL (es decir enrutable por todo
Internet).
Mencionamos que IANA lleva el registro de cada rango que se va asignando en:
IANA registry ipv6-unicast-address-assignments (http://www.iana.org/assignments/ipv6-unicast-address-
assignments/ipv6-unicast-address-assignments.xml
Dentro de estos registros existen ciertos segmentos de las direcciones que comienzan
con 2 que se han asignado a diferentes zonas y tareas, a continuacin
presentamos una captura dentro de ese rango para que podamos analizar:


Como se puede apreciar, se trata de un dilogo entre dos direcciones Unicast Global
(que hemos recuadrado en rojo) que es el objetivo de esta captura:
Fuente: 2001:0:5ef5..
Destino: 2002:c8cc.
Pero llama la atencin que previo a IPv6 aparezca Internet Protocol Version 4 con
direcciones origen y destino de cuatro octetos. donde la direccin destino la
hemos recuadrado en verde y es:
Destino (IPv4): 200.204.2.101
Si analizamos la tabla de IANA registry ipv6-unicast-address-assignments que presentamos en el
desarrollo, podemos ver estos dos rangos IPv6 origen y destino. En ambos casos se
tata de metodologas de encapsulamiento o Tnel. El primero de ellos es
justamente un modelo de tnel que se llama Teredo y como podemos ver lo define la
RFC-4380, y el segundo 6to4 es la forma de transmitir IPv6 sobre IPv4 regulado por
la RFC-3056. Ambos casos los trataremos en detalle en el futuro artculo sobre
Encapsulamiento y tneles en IPv6 y por esa razn es que no hemos querido
tratarlo en el presente, slo presentando esta captura como un ejemplo de
direccionamiento Unicast Global con esta particularidad. Abajo podemos ver las dos
lneas de los registros de IANA en las que figuran estos rangos.
2001:0000::/23 IANA 1999-07-01 whois.iana.org ALLOC [RFC2928]. 2001:0000::/32 is reserved

for TEREDO [RFC4380]. 2001:0002::/48
is reserved for Benchmarking
[RFC5180]. 2001:10::/28 is reserved for
ORCHID [RFC4843].
2002:0000::/16 6to4 2001-02-01 ALLOC 2002::/16 reserved for 6to4 [RFC3056].

Sobre lo que merece la pena detenernos, pues es parte de este artculo, es en esta
direccin destino, que en cierta forma s est cumpliendo con un mtodo que hemos
presentado al principio de este texto, y es la representacin de una IPv4 al final de una
direccin IPv6 que tal cual mencionamos en el punto 3.1. existen tres formas de
representarla, una de ellas es justamente esta:
x:x:x:x:x:x:d.d.d.d
Si analizamos la IPv4 destino, esta es: 200.204.2.101
Si analizamos la IPv6 destino, esta es: : 2002:c8cc:265:c8cc:265
Comencemos de atrs hacia delante:

265 (h) = 02(h) y 65(h) que en binario es: 0000 0010 y 0110 0101
c8cc (h) = c8(h) y cc(h) que en binario es: 1100 1000 y 1100 1100
Para pasar de hexadecimal (que opera sobre cuartetos) a valores IP
expresados en decimal (que opera sobre octetos), como es natural, se juntan
ambos cuartetos formando un octeto y se considera su peso posicional
respecto a a los ocho bits (no respecto a: cuatro y cuatro), abajo ponemos el
caso de ejemplo en concreto:
1 2 3 4 5 6 7 8 Bits
8 4 2 1 8 4 2 1 Peso en hexadecimal
0 2 octeto (h)
0 0 0 0 0 0 1 0
128 64 32 16 8 4 2 1 Peso como octeto
2
2 2 En decimal
1 2 3 4 5 6
7 8 Bits
8 4 2 1 8 4
2 1 Peso en hexadecimal
6 5 octeto (h)
0 1 1 0 0 1 0 1
128 64 32 16 8 4 2 1 Peso como octeto
64 32 4 1
64+32+4+1 = 101 101 En decimal
1 2 3 4 5 6
7 8 Bits
8 4 2 1 8 4
C 8 octeto (h)
1 1 0 0 1 0 0 0
128 64 32 16 8 4 2 1 Peso como octeto
128 64 8
128+64+8 = 200 200 En decimal
1 2 3 4 5 6
7 8 Bits
8 4 2 1 8 4
C c octeto (h)
1 1 0 0 1 1 0 0
128 64 32 16 8 4 2 1 Peso como octeto
128 64 8 4
128+64+8+4 = 204 204 En decimal
Por lo que podemos ver entonces, que los ltimos valores en hexadecimal de la
IPv6: c8cc:265, estn representando en decimal la direccin IPv4:
200.204.2.101.


IP versin 6 (Parte 03) - Encabezado.

Madrid, setiembre de 2013.


1. Presentacin.

Este tercer artculo de la serie presenta cmo est definido y se debe trabajar con el
encabezado de IP versin 6. Como iremos viendo, en virtud de su nuevo esquema de
direccionamiento, en que varios de sus campos son nuevos, otros que modifican su
funcionalidad y algunos que son eliminados, se genera bastante documentacin al
respecto. Hemos intentado resumir todo lo posible, centrndonos en los aspectos de
mayor importancia, y como siempre manteniendo un formato eminentemente tcnico,
basado en las RFC que lo regulan.

2. Introduccin.

El desarrollo se basar en una serie de RFCs, que son las siguientes:

RFC 2460 Internet Protocol, Version 6 (IPv6) Specification
RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers
RFC 2780 IANA Allocation Guidelines For Values In the Internet Protocol and
Related Headers
RFC 4727 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP
Headers
RFC 5871 IANA Allocation Guidelines for the IPv6 Routing Header
RFC 6564 A Uniform Format for IPv6 Extension Headers



3. Desarrollo.

3.1. La RFC 2780 IANA Allocation Guidelines For Values In the Internet Protocol and
Related Headers.
Vamos a iniciar este artculo con la sola mencin de esta RFC de marzo del ao 2000
pues es la que deberamos tomar como referencia inicial y gua para comprender todos
los campos de este encabezado del protocolo IP (tanto en su versin 4 como en la 6), la
misma es una especie de gua con definiciones y referencias de todos los valores y
significados de los campos que componen este encabezado, a partir del punto 5. IANA
Considerations for fields in the IPv6 header es donde encontrars todos estos aspectos.
No merece la pena que le dediquemos tiempo en este artculo pues sera una
traduccin textual de la misma. Nuestro consejo es que cada vez que necesites ampliar
un tema o comprender con mayor detalle algn significado del encabezado de IPv6, te
dirijas a esta RFC y comiences por aqu tu bsqueda.

3.2. La RFC 2460 Internet Protocol, Version 6 (IPv6) Specification.

Al principio de esta RFC nos comenta un poco la evolucin desde la versin 4, luego
habla de su Terminologa (merece la pena darle una mirada a este aspecto), pero
nosotros nos centraremos a partir del punto 3. IPv6 Header Format de la misma
donde nos presenta su encabezado de la siguiente forma:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Se puede apreciar que est agrupado en bloques de 32 bits por lnea, separando varios
campos, describe cada uno de ellos de la siguiente manera:

Version: 4 bit donde debe figurar el valor 6.
Traffic Class: 8 bit que se describen en la seccin 7 de esta RFC.
Flow Label: 20 bit que se describen en la seccin 6 de esta RFC.
Payload Length: 16 bit (entero sin signo). Se trata de la longitud del campo de
datos (Payload de IPv6) en octetos. Se debe tener en cuenta aqu que cualquier
cabecera en extensin que est presente, ser considerada tambin payload
por lo tanto incluida tambin en este campo.
Next Header: 8 bit selector. Identifica el protocolo que tiene en su nivel
inmediatamente superior. Emplea los mismos valores que IPv4.
Hop Limit: 8 bit (entero sin signo). Al igual que IPv4 este valor es
decrementado en 1 por cada salto que pase, al llegar a cero, el paquete es
descartado.
Source Address: 128 bit que identifican la direccin origen.
Destination Address: 128 bit que identifican a la direccin destino.

A continuacin presentamos un ejemplo de este encabezado:

Imagen 1: En esta imagen, se puede apreciar la captura de un encabezado bsico de
IPv6, hemos aclarado en rojo cada uno de sus campos, y en verde si se desea corroborar
el tamao de 40 Bytes de este encabezado bsico.

Esta RFC-2460 contina en el punto 4. IPv6 Extension Headers desarrollando el
funcionamiento de estos Encabezados de extensin. En IPv4, lo realizaba a travs del
campo Opciones, como parte del encabezado IPv4 (de hecho, luego de los primeros
cuatro bits de IPv4 que se corresponden al campo Versin, en IPv4 vienen cuatro bits
ms que identifican la Longitud de Cabecera en palabras de 4 Bytes, cosa que ya no es
as en IPv6). IPv6 define que estos Encabezados de Extensin son informacin

adicional, encapsulada en encabezados separados que pueden ubicarse entre el

encabezado de IPv6 y el del nivel superior. Para ser estricto con el funcionamiento de
un modelo de capas, esto suena medio chocante, pero as se ha definido y no hay ms
que hablar. Entonces, lo que estamos diciendo con los Encabezados de Extensin
para entenderlo con sencillez, es que se trata de una especie de nuevo encabezado
que se sita entre el nivel de red y el de transporte.

Continuando con el punto 4 de esta RFC, este menciona que hay un pequeo nmero
de estos encabezados identificados por un valor que ya est definido y se insertar en
el campo de 8 bits Next Header que acabamos de mencionar, y aclara que IPv6 puede
soportar: cero, uno, o ms de estos encabezados; cada uno de ellos deber ser
identificado por el campo Next Header del precedente encabezado (sea el bsico o
cada uno de los encabezados de extensin que se agreguen), poniendo los siguientes
ejemplos:
+---------------+------------------------
| IPv6 header | TCP header + data
| |
| Next Header = |
| TCP |
+---------------+------------------------
+---------------+----------------+------------------------
| IPv6 header | Routing header | TCP header + data
| | |
| Next Header = | Next Header = |
| Routing | TCP |
+---------------+----------------+------------------------
+---------------+----------------+-----------------+----------------
| IPv6 header | Routing header | Fragment header | fragment of TCP
| | | | header + data
| Next Header = | Next Header = | Next Header = |
| Routing | Fragment | TCP |
+---------------+----------------+-----------------+----------------

Estos encabezado de extensin no son examinados en ningn nodo intermedio, es
decir slo los analizan los nodos destino (sea uno slo cuando es Unicast, o sean varios
en el caso de Multicast). La nica excepcin a este anlisis intermedio es el
encabezado de extensin: Salto a Salto , que DEBE encontrarse inmediatamente a
continuacin del encabezado bsico y su existencia queda identificada por el valor
cero en el campo Next Header. (Ms adelante en este texto, veremos que en la
actualidad este aspecto tiene sus excepciones).

Cada Encabezado de extensin debe tener una longitud mltiplo de 8 octetos (o
Bytes) para mantener la alineacin en 8 Bytes del siguiente encabezado (en IPv4 es
similar, pero en mltiplos de 4 Bytes).

IPv6 a fecha de hoy tiene definido los siguientes encabezados de extensin:

Hop-by-Hop Options
Routing (Type 0: este es el nico tipo de Routing, que como veremos ms

adelante est definido por esta RFC)

Fragment
Destination Options
Authentication
Encapsulating Security Payload

Los primeros cuatro estn definidos en esta RFC y los dos ltimos en la RFC-2402 y la
RFC-2406 respectivamente, que desarrollaremos brevemente ms adelante y con
detalle cuando publiquemos el artculo de Seguridad en IPv6 pues se tratan de
IPSec.

Si bien no lo impone, la RFC-2460, recomienda que cuando exista ms de un
encabezado por extensin dentro de un mismo paquete, los mismos se coloquen en el
siguiente orden:
a. IPv6 header
b. Hop-by-Hop Options header
c. Destination Options header
d. Routing header
e. Fragment header
f. Authentication header
g. Encapsulating Security Payload header
h. Destination Options header
i. upper-layer header

Cada Encabezado de extensin debe aparecer como mximo una vez. Con la nica
excepcin de Destination Options que puede aparecer un mximo de dos veces.
Tambin aclara que si el nivel superior es otro encabezado de IPv6 (por ejemplo en
tneles IPSec) este nuevamente puede tener sus propios encabezados de extensin

Continuando con la misma RFC, el punto 4.2. Options, explica que hay dos
encabezados de extensin (Hop by Hop y Destination Options) cuya longitud es
variable, y para identificarla transporta o incorpora un formato especial llamado
Type-Length-Value (TLV), que estar inserto dentro del campo opciones del
encabezado convencional de todo encabezado de extensin, est definido como se
presenta a continuacin:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type: 8-bit que identifican el tipo de Opcin.
Opt Data Len: 8-bit (entero sin signo). Longitud del campo de opcin de
datos (solo para esta opcin). Esta es justamente la longitud mencionada.
Option Data: datos especficos de esta Opcin.

La secuencia de opciones en un encabezado DEBE ser procesada estrictamente en el

orden en el que aparecen dentro del mismo, un receptor NO DEBE indagar dentro de
un encabezado buscando un valor en particular o una determinada clase de opciones o
procesarla.

El punto siguiente 4.3. Hop by Hop Options Header como su nombre lo indica define
como debe ser tratada esta opcin de Salto por Salto, esta opcin queda identificada
con el valor 0 en el campo Next Header del encabezado bsico de IPv6, y su formato
es el siguiente:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header: 8-bit. Identifica el tipo de encabezado que contina a este mismo,
emplea los mismos valores que IPv4.
Hdr Ext Len: 8-bit (entero sin signo). Define la longitud de esta cabecera de
extensin en unidades de 8 Bytes, sin incluir los primero 8 Bytes.
Options: Campo de longitud variable. Debe ser un entero mltiplo de 8 bytes
donde figure la informacin de cada salto. Dentro del mismo contendr uno o
ms TLV (que acabamos de describir en el prrafo anterior).
A continuacin presentamos una imagen donde se puede apreciar cada uno de estos
campos:

Imagen 2: En esta imagen, se puede apreciar la captura de un encabezado de extensin Hop

by Hop, en el cual hemos destacado en rojo todos sus campos, y en verde los dos TLV que en
este caso cuenta el mismo.

Vamos a alterar el orden de esta RFC para cerrar este tema de los encabezados de
extensin de longitud variable, es decir el anterior (Hop by Hop) y ahora Destination
Options que se describe en el punto 4.6 de la misma. Esta opcin se emplea para
transportar informacin opcional que solo debe ser examinada en los nodos destino.
Este encabezado en extensin se identifica por al valor 60 del encabezado
inmediatamente precedente.
En cuanto al formato de este encabezado es exactamente igual al anterior, as que no
nos detendremos en ello.

Volviendo al orden de esta RFC, vamos a desarrollar brevemente los dos encabezados
de extensin que siguen la puntuacin. El primero de ellos es el que se trata en el
punto 4.4 Routing Header . Se emplea por quien enva el paquete IPv6 para listar
uno o ms nodos intermedios deben ser visitados en su camino hacia el nodo destino,.
Esto en realidad no es ninguna novedad en cuanto a su lgica pues en IPv4 se
empleaba de forma similar con las opciones Loose Source y Record Route. Este
encabezado de extensin se lo reconoce por el valor 43 en el encabezado
inmediatamente precedente, y su formato es el siguiente:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hdr Ext Len: 8-bit (entero sin signo). Define la longitud de esta cabecera de
extensin en unidades de 8 Bytes, sin incluir los primero 8 Bytes.
Routing Type: 8-bit. Identifica alguna variante de un encabezado particular de
enrutado.
Segments Left: 8-bit (entero sin signo). Nmero de segmentos de ruta que
completan este encabezado.
Type-specific data: Campo de longitud variable de formato determinado por el
Routing Type (que veremos a continuacin).

En estos 8-bit de Routing Type, esta RFC slo define el valor 0 para este campo (tal
cual mencionamos al principio de este texto). Para este valor, el formato de este
encabezado de extensin es el siguiente:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type=0| Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[1] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[2] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[n] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Como podemos apreciar, los nicos campos nuevos que vemos ahora son:

Reserved: 32-bit. Que deben ser inicializado a 0 por el nodo origen e
ignorados por el receptor.
Address[1..n]: Vector de 128-bit de direcciones IPv6, numeradas de 1 a n.

En este tipo de enrutado NO DEBEN aparecer direcciones Multicast, ni tampoco en el
encabezado bsico de estos paquete.
Este encabezado no es examinado o procesado hasta que el mismo alcanza el nodo
identificado en el campo Direccin Destino del encabezado bsico de IPv6. Recin al
alcanzar ese nodo, se evala la opcin Next Header del encabezado IPv6 y all se
ejecuta un algoritmo que describe en detalle esta RFC, pero que nosotros lo
explicaremos a travs del ejemplo que esta recomendacin propone y que es el
siguiente.
Supongamos que un nodo fuente S enva un paquete al nodo destino D empleando
el encabezado de extensin Routing para que el paquete pase por los nodos
intermedios I1, I2 e I3 paquete viaja desde S hasta I1. Los campos de sus
encabezados seran los siguientes:


Primer paquete IPv6:

Source Address = S Hdr Ext Len = 6
Destination Address = I1 Segments Left = 3
Address[1] = I2
Address[2] = I3
Address[3] = D
Segundo paquete IPv6:
Address[1] = I1
Address[2] = I3
Address[3] = D
Tercer paquete IPv6:
Address[1] = I1
Address[2] = I2
Address[3] = D
Cuarto paquete IPv6:
Destination Address = D Segments Left = 0
Address[1] = I1
Address[2] = I2
Address[3] = I3
Es decir, cada nodo intermedio, analiza la direccin destino, cuando se corresponde a
la propia, luego procesa Next Header, al ver que existe la opcin Routing, mira el
Type si es igual a 0, esta valor es correcto por lo tanto pasa a analizar el campo
Segments Left (para nosotros es: Segmentos restantes), sobre la base de ese
campo, genera un nuevo encabezado IPv6 bsico con este nuevo nodo intermedio
como direccin IP destino (reiteramos: dentro del encabezado bsico, no en el de
extensin) y enva este nuevo paquete hacia el prximo nodo intermedio,
decrementando el valor del campo Segments Left y rotando el orden de los nodos
intermedios, este proceso se repite hasta que el valor Segments Left es igual a 0 que
indica que se trata del ltimo paquete y es el nodo destino.
El punto que contina en esta RFC es el 4.5 Fragment Header, estos encabezados de
fragmentacin, los emplea nuevamente un nodo fuente para enviar paquetes que
recibe de un nivel superior y cuyo tamao es superior a lo que IPv6 calcula como MTU
(Maximun Transfer Unit), que como hemos desarrollado en artculos anteriores, es la
metodologa que emplea IPv6 para determinar cul es la cantidad mxima de Bytes
que pueden enviar de extremo a extremo de esta ruta entre origen y destino.
Nuevamente recalca que a diferencia de IPv4, la fragmentacin en IPv6 no puede ser
realizada por los routers intermedios, sino nicamente por los nodos origen y destino.
Este encabezado de extensin se reconoce por el valor 44 en el encabezado que
inmediatamente lo precede y tiene el siguiente formato:



+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reserved: 8-bit que se corresponde a un campo reservado (es decir que no se
deben emplear). Deben ser inicializados a 0 por el transmisor e ignorados en
el receptor.
Fragment Offset: 13-bit (entero sin signo). Se mide en unidades de 8 octetos (64
bits) e indica en que parte del paquete original deben ser re ensamblados los
datos que aqu estn contenidos, por esa razn el primer paquete que
transporte los datos fragmentados, llevar el valor 0 en este campo.
Res: 2-bit otro campo reservado dem al anterior.
M flag: Indica si existen ms fragmentos o se trata del ltimo fragmento.
Cuando su valor es 1 = more fragment; Si es 0 = last fragment.
Identification: 32-bits. Este valor ser el que identifique a todos los
fragmentos que formen parte del mismo envo. La RFC sugiere que este valor
sea diferente a cualquier otro que se haya generado recientemente entre la
misma fuente y destino y se define el concepto de recientemente (no merece
la pena detenernos en ello).
La RFC contina detallando el funcionamiento de este encabezado de fragmentacin,
pero nosotros en este artculo no lo haremos pues su lgica funciona exactamente igual
que como se haca en IPv4 ( y puede verse con todo detalle en el libro Seguridad por
Niveles), con la nica salvedad que:
Los 3 campos que se emplean para Fragmentacin (M Flag, Fragment Offset e
Identification) en IPv4 se llamaban igual, pero estaban dentro de los veinte
Bytes del encabezado bsico.
De estos mismos 3 campos, los dos primeros tienen la misma longitud, el
tercero (Identification) ahora es el doble, en IPv4 era de 16 bits.
Estos campos slo viajan cuando se emplea encabezado de extensin para
Fragmentacin. En IPv4 estaban presentes en todos los datagramas pues
formaban parte de los 20 bytes de su encabezado mnimo (si no se empleaba
fragmentacin sus valores eran 0).
NOTA: Un detalle que viene al caso mencionar es que en IPv4 existe otro bit que
guarda estrecha relacin con esta actividad, se trata del bit DF (Don`t Fragment).
Este bit se empleaba para ordenar que ese paquete en concreto no poda ser
fragmentado por ningn nodo intermedio (el caso tpico, por ejemplo, era el de un
triple Handshake de su protocolo superior TCP, este caso s o s deben ser tres
paquetes, por lo tanto si en algn nodo intermedio se empleara fragmentacin,
entonces no se podra lleva a cabo esta secuencia en el nivel superior con el
protocolo TCP, por lo tanto los tres datagramas lo ponan a 1). Como hemos
repetido ya varias veces, en IPv6 slo pueden fragmentar los nodos origen y
destino, por lo que deja de tener sentido el empleo de este bit y por esa razn en
IPv6 no existe.
El punto 4.6 de esta RFC, es Destination Option que ya lo habamos desarrollado
alterando el orden (para analizar conjuntamente los dos encabezados de extensin de
longitud variable: Hop by Hop y Destination Options) as que pasaremos al punto 4.7
No Next Header este encabezado se identifica con el valor 59 en el campo Next
Header del encabezado que lo precede inmediatamente, e indica sencillamente que no
existe ningn otro encabezado que contine a este mismo.
A continuacin presentamos una imagen de esta caso:

Imagen 3: En esta imagen, se puede apreciar el valor 59 (No Next Header) y en la parte
inferior, nuevamente resaltado en naranja los 40 bytes de este encabezado, donde se ve
claramente que all acaba este paquete, es decir no contina ningn otro protocolo.

El punto 5. Packet Size Issues aconseja que se empleen tamaos de paquetes no
inferiores a 1280 bytes, y entra en mayores detalles sobre cundo se aconseja o no
fragmentar, no nos detendremos en ello.
El punto 6. Flow Labels, presenta cmo estos 20 bit de etiquetas de flujo pueden se
empleados por un nodo fuente para especiales solicitudes en el control de las rutas de
ese paquete por los routers configurados con IPv6. A la fecha de la publicacin de esta
RFC (diciembre de 1998) an se encontraban en uso experimental, y solo aclara que
los routers que no controlen an estos parmetros deben pasarlos en forma
transparente y sin ejecutar modificaciones sobre estos bits.
Para las definiciones vigentes al da de hoy, La RFC-6437 IPv6 Flow Label
Specification actualiza algunos conceptos. La mencionada RFC, inclusive
aclara que esta reemplaza a la RFC-3697 y justamente al punto 6, y Apndice A
de la RFC-2460.
Volvamos a la RFC-2460 y sigamos con el punto 7. Traffic Classes
Este campo, de 8 bits est disponible para poder distinguir entre diferentes clases o
prioridades de los paquetes IPv6. Menciona que a la fecha de esta RFC, ya existen
varias pruebas sobre IPv4 de priorizacin de trfico empleando los campos

Precedencia y Tipo de Servicio de esta versin anterior, estos trabajos se

denominan Servicios diferenciados, y la idea para IPv6 es similar. (Se debe tener en
cuenta que a da de hoy para IPv4, tambin existe otro concepto que es el de Servicios
Integrados, que opera tambin de forma parecida).
En realidad para desarrollar este campo, debemos considerar la RFC 2474
Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers, de la que slo comentaremos que se trata de una propuesta, no es
mandatoria, y que en pocos prrafos podramos describir que:
La estructura que propone de estos 8 bit es la siguiente:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+
DSCP: differentiated services codepoint
CU: currently unused
Es decir propone no usar los ltimos dos bits y se centra en los seis primeros, y
tal vez lo ms importante lo trata el punto 6 de esta RFC: IANA Considerations,
que establece lo siguiente:
Este espacio de direcciones ofrece 64 opciones (los seis primeros bits del
octeto) llamados codepoints, (de all viene la abreviatura DSCP:
Differentiated Services Code Points), este espacio est dividio en tres
pooles para propsito de asignacin y administracin de codepoints
de acuerdo a la siguiente tabla:
Pool Codepoint space Assignment Policy
---- --------------- -----------------
1 xxxxx0 Standards Action
2 xxxx11 EXP/LU
3 xxxx01 EXP/LU (*)
Pool 1: Para ser asignado a acciones estndar.

Pool 2: Reservado para uso local o experimental.
Pool 3: Inicialmente dem al anterior, pero debera ser preferentemente
empleado para acciones estndar si se agota el pool 1.
A continuacin presentamos una imagen de este campo:

Imagen 4: En esta imagen, se puede apreciar la captura de un encabezado que emplea

justamente el campo Traffic Class, este caso como podemos ver, respeta los dos
ltimos bits de este octeto (puestos a cero), luego de los seis primeros emplea el valor
111000 por lo que nos encontraramos concretamente dentro del Pool 1, es decir
una accin estndar.

Por ltimo volviendo al punto 8 de la RFC 2460, este describe las caractersticas de los
niveles superiores para IPv6, iniciando este tema con la aclaracin que cualquier
protocolo de nivel superior que emplee el direccionamiento IP para verificacin
(Checksum) deber considerar ahora los 128 bits en vez de los 32 de IPv4. En
particular especifica cmo trabajar con los Pseudo header de TCP y UDP, pero no nos
detendremos en ello.
Este mismo punto hace referencia al cambio de nomenclatura de TTL de IPv4 por Hop
Limit de IPv6, pero su lgica sigue siendo la misma, y luego aclara que los protocolos
de nivel superior cuando calculan el mximo tamao de datos que pueden entregar
ahora al nivel 3, deben tener en cuenta que antes por ejemplo deban dejar 20 byte
para TCP y 20 para IP, ahora debern dejar, en este mismo caso 20 para TCP y 40 para
IPv6), es decir contemplar que sern (en el caso de TCP) 60 bytes en vez de los 40 que
reservaban para IPv4.
No entraremos a desarrollar los anexos de esta RFC, pero si alguien desea profundizar,
sobre todo en como se empaquetan los distintos encabezados de extensin variable,
en el anexo B ofrece varios ejemplos muy claros.

3.3. Las RFC 2402 y 2406 IP Authentication Header (AH) e IP Encapsulating Security
Payload (ESP).

En el punto anterior, cuando comentamos el tema de los encabezados en extensin, los
dos ltimos que se presentan son justamente estos dos, ambos conforman el ncleo de
lo que se conoce como IPSec, en grandes rasgos el primero (AH) ofrece las opciones
de autenticacin e integridad de datos y el segundo (ESP) se emplea para
confidencialidad. En este artculo no nos detendremos en IPSec, solamente queremos
mencionar que de forma nativa todo IPSec fue concebido para operar sobre IPv6, por
esa razn es que su ms eficiente funcionamiento es justamente como encabezados en
extensin de IPv6.
El funcionamiento de ambos est descrito en las RFC que mencionamos en el ttulo de
este punto, en estos prrafos, solamente ponemos de manifiesto cmo estas
recomendaciones describen el empleo de estos encabezados en extensin:
La RFC 2402 (AH) en su punto 3.1 Authentication Header Location nos describe que
en el contexto de IPv6, AH es visto como un payload (carga, datos) de extremo a
extremo y debera aparecer como un encabezado en extensin luego de las opciones
hop-by-hop, routing, and fragmentation:

Encabezado antes de aplicar AH

---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
Encabezado despus de aplicar AH

------------------------------------------------------------
IPv6 | |hop-by-hop, dest*, | | dest | | |
|orig IP hdr |routing, fragment. | AH | opt* | TCP | Data |
------------------------------------------------------------
* = si est presente podra estar antes de AH, despus de AH, o ambos

Para el caso de la RFC 2406 (ESP) el punto es el mismo 3.1 ESP Header Location y nos
presenta tambin un esquema muy similar:
Encabezado antes de aplicar ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
Encabezado despus de aplicar ESP
---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth|
---------------------------------------------------------
|<---- encrypted ---->|
|<---- authenticated ---->|
* = si est presente podra estar antes de ESP, despus de ESP, o ambos

A continuacin presentamos una imagen de IPv6 empleando ESP:

Imagen 5: En esta imagen podemos apreciar justamente este protocolo, en esta captura
no hay ninguna opcin intermedia, por lo tanto IPv6 lo indica como Next Header = 50, e

inmediatamente finalizado el encabezado bsico de IPv6 comienza ESP. Si se presta

atencin en la parte inferior de la imagen, luego de los 40 octetos (en hexadecimal) del
encabezado de IPv6 (que hemos resaltado en naranja), contina ESP con los campos de
su encabezado 00 00 00 0a (ESP SPI) 00 00 00 04 (Secuencia) y a continuacin todo lo
que sigue va criptografiado, pues esa es la funcin de ESP.

3.4. La RFC 6564 A Uniform Format for IPv6 Extension Headers

Hemos incluido esta RFC de abril de 2012 pues se trata de una actualizacin de la
anterior (RFC 2460).
Lo ms importante a destacar, es que tal cual describe en su introduccin, la RFC 2460
estableca que los encabezados en extensin, con excepcin del Hop by Hop no deben
ser procesados en nodos intermedios, pero en la actualidad muchos desarrollos de
IPv6 sobre routers y firewalls son capaces de procesar y/o ignorar cualquiera de ellos
empleando lo que se denomina ASICs: Application Specific Integrated Circuits, en
particular se evalu esta RFC por razones de seguridad.
Para evitar problemas en nodos intermedios, cualquier encabezado en extensin
definido a futuro deber respetar el siguiente formato:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Header Specific Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Este esquema no debe ser tenido en cuenta para los encabezados ya definidos con
anterioridad (RFC-2460) slo aplica a nuevos encabezados en extensin.



Introduccion IPV6 - Alejandro Corletti

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduccion IPV6 - Alejandro Corletti

Uploaded by

Copyright:

Available Formats

Los Pases de habla hispana podemos ser pioneros en IPv6,

por mi parte tengo toda la FE puesta en que es posible.

IP versin 6 (Parte 01) - Sus componentes.

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 2

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 3

relacionado con el control de ventana de envo y recepcin para el caso de TCP, el

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 4

1) Protocolo ND (Network Discovery).

Neighbor Discovery for IP version 6 (IPv6) 4861 Internet Standard (STD)

Algunas de las funciones ms importantes que realiza son:

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 5

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 6

Fuimos probando conexiones con diferentes telfonos mviles con el

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 7

Al slo efecto de presentar brevemente estas novedades de IPv6 respecto al

Proposed Standard (PS)

Proposed Standard (PS)

Proposed Standard (PS)

Proposed Standard (PS)

Transmission of Ipv6 Packets over IEEE 1394 Networks 3146

Proposed Standard (PS)

Internet Standard (STD)

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 8

relacionado a escuchas de multicast, solicitudes y advertencias de rutas y de

Proposed Standard (PS)

Multiprotocol Extensions for BGP-4 4760 Draft Standard (DS)

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 9

sensiblemente a todos los elementos responsables del manejo de rutas y

Dynamic Host Configuration Protocol for Ipv6 (DHCPv6) 3315

Proposed Standard (PS)

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 10

Dynamic Host Configuration Protocol (DHCPv6) Options

Ipv6 Prefix Options for Dynamic Host Configuration

DNS Configuration options for Dynamic Host

Stateless Dynamic Host Configuration Protocol (DHCP)

Network Information Service (NIS) Configuration

Dynamic Host Configuration Protocol for Ipv6 (DHCPv6)

Dynamic Host Configuration Protocol for Ipv6 (DHCPv6)

The Dynamic Host Configuration Protocol for Ipv6

Option Proposed Standard (PS)

Information Proposed Standard (PS)

DHCPv6 Leasequery 5007

DHCPv6 Bulk Leasequery 5460

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 11

Best Current Practice

Internet Standard (STD)

Como se puede apreciar el valor importante que viaja aqu es justamente el de

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 12

Todas estas nuevas caractersticas aplican a los siguientes protocolos y se definen

Proposed Standard (PS)

Proposed Standard (PS)

Proposed Standard (PS)

Proposed Standard (PS)

Diameter Mobile IPv6: Support for Home Agent to

Diameter Proxy Mobile IPv6: Mobile Access Gateway and

Network Information Service (NIS) Configuration

IPv6 (DHCPv6) Proposed Standard (PS)

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 13

Network Time Protocol (NTP) Server Option for

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 14

4. Capturas de trfico ejemplos.

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 15

Si alguien tiene intencin de profundizar an ms sobre ND, dejamos a continuacin

IPv6 no es cuestin de dinero, se trata de esfuerzo, voluntad y FE en lograrlo Pg 17