¿Tiene una cuenta?
Este documento proporciona información sobre la teoría del funcionamiento y la configuración de la solución Cisco Unified Wireless LAN en relación al soporte de los clientes IPv6.
Conectividad del cliente inalámbrico IPv6
El conjunto de funciones IPv6 de la versión 7.2 del software Cisco Unified Wireless Network permite que la red inalámbrica admita clientes IPv4, de doble pila e IPv6 únicamente en la misma red inalámbrica. El objetivo general de la incorporación de la compatibilidad con clientes IPv6 a la LAN inalámbrica unificada de Cisco era mantener la paridad de funciones entre los clientes IPv4 e IPv6, incluida la movilidad, la seguridad, el acceso de invitados, la calidad del servicio y la visibilidad de terminales.
Se puede realizar un seguimiento de hasta ocho direcciones de cliente IPv6 por dispositivo. Esto permite a los clientes IPv6 tener una dirección local de enlace, configuración automática de direcciones sin estado (SLAAC), dirección del protocolo de configuración dinámica de host para IPv6 (DHCPv6) e incluso direcciones en prefijos alternativos para estar en una única interfaz. Los clientes de puente de grupo de trabajo (WGB) conectados al enlace ascendente de un punto de acceso autónomo (AP) en modo WGB también pueden admitir IPv6.
No hay requisitos específicos para este documento.
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
Controladores LAN inalámbricos serie 2500, serie 5500 o WiSM2
AP 1130, 1240, 1250, 1040, 1140, 1260, 3500, 3600 Series AP y 1520 o 1550 Series Mesh AP
Router compatible con IPv6
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Para habilitar la conectividad del cliente IPv6 inalámbrico, la red con cables subyacente debe admitir el ruteo IPv6 y un mecanismo de asignación de direcciones como SLAAC o DHCPv6. El controlador de LAN inalámbrica debe tener adyacencia L2 al router IPv6, y la VLAN debe etiquetarse cuando los paquetes ingresan al controlador. Los AP no requieren conectividad en una red IPv6, ya que todo el tráfico se encapsula dentro del túnel CAPWAP IPv4 entre el AP y el controlador.
El método más común para la asignación de direcciones de cliente IPv6 es SLAAC. SLAAC proporciona conectividad plug-and-play sencilla en la que los clientes autoasignan una dirección basada en el prefijo IPv6. Este proceso se logra cuando el router IPv6 envía mensajes periódicos de anuncio de router que informan al cliente del prefijo IPv6 en uso (los primeros 64 bits) y del gateway predeterminado IPv6. A partir de ese punto, los clientes pueden generar los 64 bits restantes de su dirección IPv6 basándose en dos algoritmos: EUI-64 que se basa en la dirección MAC de la interfaz, o direcciones privadas que se generan aleatoriamente. La elección del algoritmo depende del cliente y a menudo es configurable. Los clientes IPv6 realizan la detección de direcciones duplicadas para garantizar que las direcciones aleatorias que se seleccionan no choquen con otros clientes. La dirección del router que envía anuncios se utiliza como la gateway predeterminada para el cliente.
Estos comandos de configuración de Cisco IOS® de un router IPv6 compatible con Cisco se utilizan para habilitar el direccionamiento SLAAC y los anuncios del router:
ipv6 unicast-routing interface Vlan20 description IPv6-SLAAC ip address 192.168.20.1 255.255.255.0 ipv6 address 2001:DB8:0:20::1/64 ipv6 enable end
El uso de DHCPv6 no es necesario para la conectividad del cliente IPv6 si SLAAC ya está implementado. Hay dos modos de funcionamiento para DHCPv6 llamados Stateless y Stateful.
El modo sin estado DHCPv6 se utiliza para proporcionar a los clientes información de red adicional no disponible en el anuncio del router, pero no una dirección IPv6, ya que SLAAC ya lo proporciona. Esta información puede incluir el nombre de dominio DNS, los servidores DNS y otras opciones específicas del proveedor DHCP. Esta configuración de interfaz es para un router IPv6 de Cisco IOS que implementa DHCPv6 sin estado con SLAAC habilitado:
ipv6 unicast-routing interface Vlan20 description IPv6-DHCP-Stateless ip address 192.168.20.1 255.255.255.0 ipv6 enable ipv6 address 2001:DB8:0:20::1/64 ipv6 nd other-config-flag ipv6 dhcp relay destination 2001:DB8:0:10::100 end
La opción DHCPv6 Stateful, también conocida como modo administrado, funciona de manera similar a DHCPv4 en el sentido de que asigna direcciones únicas a cada cliente en lugar de al cliente que genera los últimos 64 bits de la dirección como en SLAAC. Esta configuración de interfaz es para un router IPv6 de Cisco IOS que implementa DHCPv6 con estado con SLAAC desactivado:
ipv6 unicast-routing interface Vlan20 description IPv6-DHCP-Stateful ip address 192.168.20.1 255.255.255.0 ipv6 enable ipv6 address 2001:DB8:0:20::1/64 ipv6 nd prefix 2001:DB8:0:20::/64 no-advertise ipv6 nd managed-config-flag ipv6 nd other-config-flag ipv6 dhcp relay destination 2001:DB8:0:10::100 end
La configuración de la red por cable para una conectividad completa de todo el campus IPv6 utilizando métodos de conectividad de pila doble o tunelización está fuera del alcance de este documento. Para obtener más información, consulte la guía de implementación validada de Cisco Implementación de IPv6 en redes de campus.
Para tratar con clientes IPv6 itinerantes a través de los controladores, los mensajes ICMPv6 como Neighbor Solicitation (NS), Neighbor Advertisement (NA), Router Advertisement (RA) y Router Solicitation (RS) deben tratarse especialmente para asegurarse de que un cliente permanezca en la misma red de Capa 3. La configuración para la movilidad IPv6 es la misma que para la movilidad IPv4 y no requiere ningún software independiente en el lado del cliente para lograr una itinerancia fluida. La única configuración necesaria es que los controladores deben ser parte del mismo grupo/dominio de movilidad.
Este es el proceso para la movilidad del cliente IPv6 entre los controladores:
Si ambos controladores tienen acceso a la misma VLAN en la que estaba originalmente el cliente, la roaming es simplemente un evento de itinerancia de Capa 2 donde el registro del cliente se copia al nuevo controlador y no se tuneliza ningún tráfico de regreso al controlador de anclaje.
Si el segundo controlador no tiene acceso a la VLAN original en la que estaba el cliente, se producirá un evento de roaming de Capa 3, lo que significa que todo el tráfico del cliente debe ser tunelado a través del túnel de movilidad (Ethernet sobre IP) al controlador de anclaje.
Para asegurarse de que el cliente retenga su dirección IPv6 original, los RAs de la VLAN original son enviados por el controlador de anclaje al controlador externo donde son entregados al cliente usando unidifusión L2 desde el AP.
Cuando el cliente itinerante va a renovar su dirección a través de DHCPv6 o a generar una nueva dirección a través de SLAAC, los paquetes RS, NA y NS siguen siendo tunelizados a la VLAN original para que el cliente reciba una dirección IPv6 que sea aplicable a esa VLAN.
Nota: La movilidad para clientes solo de IPv6 se basa en la información de VLAN. Esto significa que la movilidad del cliente solo de IPv6 no se soporta en las VLAN sin etiqueta.
La función de grupos de interfaz permite que una organización tenga una sola WLAN con varias VLAN configuradas en el controlador para permitir el balanceo de carga de clientes inalámbricos a través de estas VLAN. Esta función se utiliza comúnmente para mantener pequeños tamaños de subred IPv4 mientras se permite que una WLAN se amplíe a miles de usuarios a través de varias VLAN del grupo. Para admitir clientes IPv6 con grupos de interfaces, no se requiere ninguna configuración adicional ya que el sistema envía automáticamente el RA correcto a los clientes correctos a través de la unidifusión inalámbrica L2. Al unificar el RA, los clientes en la misma WLAN, pero una VLAN diferente, no reciben el RA incorrecto.
La función de protección de RA aumenta la seguridad de la red IPv6 al descartar los RA procedentes de clientes inalámbricos. Sin esta función, los clientes IPv6 malintencionados o mal configurados podrían anunciarse como un router para la red, a menudo con una prioridad alta que podría tener prioridad sobre los routers IPv6 legítimos.
De forma predeterminada, la protección de RA se habilita en el AP (pero se puede inhabilitar en el AP) y siempre se habilita en el controlador. Se prefiere descartar los RA en el AP ya que es una solución más escalable y proporciona contadores de caídas de RA mejorados por cliente. En todos los casos, la RA IPv6 se descartará en algún momento, lo que protege a otros clientes inalámbricos y a la red por cable ascendente de clientes IPv6 malintencionados o mal configurados.
La función DHCPv6 Server Guard evita que los clientes inalámbricos repartan direcciones IPv6 a otros clientes inalámbricos o a los clientes cableados en sentido ascendente. Para evitar que se entreguen las direcciones DHCPv6, se descartan los paquetes anunciados por DHCPv6 de los clientes inalámbricos. Esta función funciona en el controlador, no requiere configuración y se habilita automáticamente.
La función IPv6 Source Guard evita que un cliente inalámbrico falsifique una dirección IPv6 de otro cliente. Esta función es análoga a IPv4 Source Guard. IPv6 Source Guard está habilitado de forma predeterminada, pero se puede inhabilitar mediante la CLI.
Para la autenticación y la contabilización RADIUS, el controlador devuelve una dirección IP usando el atributo "Framed-IP-address". En este caso, se utiliza la dirección IPv4.
El atributo "Calling-Station-ID" utiliza este algoritmo para devolver una dirección IP cuando el "Tipo de ID de la estación de llamada" en el controlador está configurado como "Dirección IP":
Dirección IPv4
Dirección IPv6 de unidifusión global
Enlace de la dirección IPv6 local
Dado que las direcciones IPv6 del cliente pueden cambiar con frecuencia (direcciones temporales o privadas), es importante realizar un seguimiento de ellas a lo largo del tiempo. Cisco NCS registra todas las direcciones IPv6 en uso por cada cliente e históricamente las registra cada vez que el cliente avanza o establece una nueva sesión. Estos registros se pueden configurar en NCS para que se conserven hasta un año.
Nota: El valor predeterminado para el "Tipo de ID de estación de llamada" en el controlador se ha cambiado a "Dirección MAC del sistema" en la versión 7.2. Al actualizar, esto se debe cambiar para permitir el seguimiento único de los clientes por dirección MAC, ya que las direcciones IPv6 pueden cambiar a mitad de sesión y causar problemas en la contabilidad si el ID de la estación de llamada se establece en dirección IP.
Para restringir el acceso a determinados recursos cableados ascendentes o bloquear ciertas aplicaciones, se pueden utilizar listas de control de acceso (ACL) IPv6 para identificar el tráfico y permitirlo o denegarlo. Las ACL IPv6 admiten las mismas opciones que las ACL IPv4, incluidos el origen, el destino, el puerto de origen y el puerto de destino (también se admiten rangos de puertos). Las ACL de autenticación previa también son compatibles con la autenticación de invitados IPv6 mediante un servidor web externo. El controlador inalámbrico admite hasta 64 ACL IPv6 únicas con 64 reglas únicas en cada una. El controlador inalámbrico continúa admitiendo 64 ACL IPv4 únicas adicionales con 64 reglas únicas en cada una para un total de 128 ACL para un cliente de pila doble.
Para admitir el control de acceso centralizado a través de un servidor AAA centralizado como Cisco Identity Services Engine (ISE) o ACS, la ACL IPv6 se puede aprovisionar por cliente mediante atributos de anulación AAA. Para utilizar esta función, la ACL IPv6 debe configurarse en el controlador y la WLAN debe configurarse con la función de anulación AAA habilitada. El atributo AAA con nombre real para una ACL IPv6 es Airespace-IPv6-ACL-Name similar al atributo Airespace-ACL-Name utilizado para el aprovisionamiento de una ACL basada en IPv4. El atributo AAA devuelto el contenido debe ser una cadena igual al nombre de la ACL IPv6 tal como se configuró en el controlador.
El protocolo de detección de vecinos IPv6 (NDP) utiliza los paquetes NA y NS en lugar del protocolo de resolución de direcciones (ARP) para permitir que los clientes IPv6 resuelvan la dirección MAC de otros clientes en la red. El proceso NDP puede ser muy parlanchín ya que inicialmente utiliza direcciones multicast para realizar la resolución de direcciones; esto puede consumir un valioso tiempo de transmisión inalámbrico a medida que los paquetes multicast se envían a todos los clientes en el segmento de red.
Para aumentar la eficiencia del proceso NDP, el almacenamiento en caché de detección de vecinos permite que el controlador actúe como proxy y responda a las consultas NS que puede resolver. El almacenamiento en caché de detección de vecino es posible gracias a la tabla de enlace de vecino subyacente presente en el controlador. La tabla de enlace de vecino realiza un seguimiento de cada dirección IPv6 y su dirección MAC asociada. Cuando un cliente IPv6 intenta resolver la dirección de capa de link de otro cliente, el paquete NS es interceptado por el controlador que responde con un paquete NA.
La aceleración del anuncio del router permite al controlador aplicar límites de velocidad de los RA dirigidos a la red inalámbrica. Al habilitar la regulación de RA, los routers que se configuran para enviar RA muy a menudo (por ejemplo, cada tres segundos) pueden reducirse a una frecuencia mínima que mantendrá la conectividad del cliente IPv6. Esto permite optimizar el tiempo de transmisión reduciendo el número de paquetes de multidifusión que se deben enviar. En todos los casos, si un cliente envía un RS, se permitirá un RA a través del controlador y unicast al cliente solicitante. Esto es para asegurarse de que los nuevos clientes o clientes de roaming no se vean afectados negativamente por la regulación de RA.
Las funciones de invitado por cable e inalámbrico presentes para los clientes IPv4 funcionan de la misma manera para los clientes de pila doble y solo IPv6. Una vez que el usuario invitado se asocia, se colocan en el estado de ejecución "WEB_AUTH_REQ" hasta que el cliente se autentica a través del portal cautivo IPv4 o IPv6. El controlador interceptará el tráfico HTTP/HTTPS IPv4 e IPv6 en este estado y lo redirigirá a la dirección IP virtual del controlador. Una vez que el usuario se autentica a través del portal cautivo, su dirección MAC se traslada al estado de ejecución y se permite pasar tanto el tráfico IPv4 como el tráfico IPv6. Para la autenticación Web externa, la ACL de autenticación previa permite utilizar un servidor Web externo.
Para soportar la redirección de clientes sólo IPv6, el controlador crea automáticamente una dirección virtual IPv6 basada en la dirección virtual IPv4 configurada en el controlador. La dirección IPv6 virtual sigue la convención de [::ffff:<dirección IPv4 virtual>]. Por ejemplo, una dirección IP virtual de 1.1.1.1 se traduciría a [::ffff:1.1.1.1].
Cuando utilice un certificado SSL de confianza para la autenticación de acceso de invitado, asegúrese de que tanto la dirección virtual IPv4 como IPv6 del controlador esté definida en DNS para que coincida con el nombre de host de los certificados SSL. Esto asegura que los clientes no reciban una advertencia de seguridad que indique que el certificado no coincide con el nombre de host del dispositivo.
Nota: El certificado SSL generado automáticamente por el controlador no contiene la dirección virtual IPv6. Esto puede hacer que algunos navegadores web presenten una advertencia de seguridad. Se recomienda utilizar un certificado SSL de confianza para el acceso de invitado.
VideoStream permite la entrega de vídeo multidifusión inalámbrica fiable y escalable, enviando a cada cliente la secuencia en un formato de unidifusión. La conversión multicast a unicast real (de L2) ocurre en el AP que proporciona una solución escalable. El controlador envía el tráfico de vídeo IPv6 dentro de un túnel de multidifusión CAPWAP IPv4 que permite una distribución de red eficiente al AP.
Los paquetes IPv6 utilizan una marca similar al uso de valores DSCP por IPv4 que admiten hasta 64 clases de tráfico diferentes (0-63). Para los paquetes de flujo descendente de la red cableada, el valor de clase de tráfico IPv6 se copia en el encabezado del túnel CAPWAP para asegurarse de que QoS se conserva de extremo a extremo. En la dirección ascendente, ocurre lo mismo que el tráfico del cliente marcado en la Capa 3 con la clase de tráfico IPv6 se cumplirá marcando los paquetes CAPWAP destinados al controlador.
FlexConnect en el modo de conmutación local admite clientes IPv6 al puentear el tráfico con la VLAN local, similar a la operación IPv4. La movilidad del cliente es compatible con la itinerancia de capa 2 en todo el grupo FlexConnect.
Estas funciones específicas de IPv6 son compatibles con el modo de switching local FlexConnect:
Protección de RA IPv6
Puente IPv6
Autenticación de invitado IPv6 (alojada en controlador)
Estas funciones específicas de IPv6 no se admiten en el modo de switching local FlexConnect:
Movilidad de capa 3
VideoStream IPv6
Listas de Control de Acceso IPv6
Protección de Origen IPv6
Protección del servidor DHCPv6
Almacenamiento en caché de detección de vecino
Regulación del anuncio del router
Para los AP en el modo FlexConnect que utilizan switching central (tunelización del tráfico de vuelta al controlador), el controlador debe configurarse en "Multicast - Unicast Mode" para el "AP Multicast Mode". Dado que los AP de FlexConnect no se unen al grupo de multidifusión CAPWAP del controlador, los paquetes multicast se deben replicar en el controlador y unidifusión a cada AP individualmente. Este método es menos eficiente que "Multicast - Multicast Mode" y coloca carga adicional en el controlador.
Esta función específica de IPv6 no se admite en el modo de conmutación central de FlexConnect:
VideoStream IPv6
Nota: Las WLANs conmutadas centralmente que ejecutan IPv6 no se soportan en el controlador Flex 7500 Series.
Con la versión de NCS v1.1, se añaden muchas funciones específicas de IPv6 adicionales para supervisar y gestionar una red de clientes IPv6 tanto en redes por cable como inalámbricas.
Para ver qué tipos de clientes están presentes en la red, hay disponible un "Dashlet" en NCS para proporcionar información sobre las estadísticas específicas de IPv6 y ofrecer la capacidad de profundizar en los clientes IPv6.
Dashlet de tipo de dirección IP: muestra los tipos de clientes IP en la red:
Recuento de clientes por tipo de dirección IP: muestra el tipo de cliente IP a lo largo del tiempo:
Tráfico de cliente por tipo de dirección IP: muestra el tráfico de cada tipo de cliente. Los clientes de la categoría de pila doble incluyen tráfico IPv4 e IPv6:
Asignación de Dirección IPv6: muestra el método de asignación de dirección para cada cliente como una de estas cuatro categorías:
DHCPv6 - Para clientes con direcciones asignadas por un servidor central. El cliente también puede tener una dirección SLAAC.
SLAAC o Static - Para clientes que utilizan la asignación automática de direcciones sin estado o que utilizan direcciones configuradas estáticamente.
Desconocido: en algunos casos, no se puede detectar la asignación de dirección IPv6.
Esta condición sólo ocurre en los clientes con cables en NCS, ya que algunos switches no detectan la información de asignación de direcciones IPv6.
Auto-Assigned - Para clientes con solamente una dirección local de link que es totalmente autoasignada.
Los clientes de esta categoría pueden tener problemas de conectividad IPv6 ya que carecen de una dirección única global o local.
Se puede hacer clic en cada una de las secciones del gráfico circular, lo que permite al administrador desglosar hasta una lista de clientes.
Para supervisar y administrar la información del cliente IPv6, estas columnas se agregaron a la página Clientes y Usuarios:
Tipo de IP: el tipo de cliente basado en las direcciones IP que se han visto desde el cliente. Las opciones posibles son IPv4, IPv6 o Doble pila, lo que significa un cliente con direcciones IPv4 e IPv6.
Tipo de asignación de IPv6: NCS detecta el método de asignación de dirección como SLAAC o Static, DHCPv6, Self-Assigned o Unknown.
Global Unique: la dirección global IPv6 más reciente utilizada por el cliente. Un mouse sobre el contenido de la columna revela cualquier dirección IPv6 global única adicional utilizada por el cliente.
Local Unique: dirección única local IPv6 más reciente utilizada por el cliente. Un ratón sobre el contenido de la columna muestra cualquier dirección IPv6 global única adicional utilizada por el cliente.
Link Local (Enlace local): Dirección IPv6 del cliente que se asigna automáticamente y se utiliza para la comunicación antes de asignar cualquier otra dirección IPv6.
Anuncios del router descartados - El número de anuncios del router enviados por el cliente y descartados en el AP. Esta columna se puede utilizar para rastrear clientes que pueden estar mal configurados o configurados de forma maliciosa para actuar como un router IPv6. Esta columna es clasificable, lo que permite identificar fácilmente a los clientes infractores.
Además de mostrar columnas específicas de IPv6, la columna Dirección IP mostrará la dirección IP actual del cliente con prioridad para mostrar primero la dirección IPv4 (en el caso de un cliente de pila doble) o la dirección IPv6 Global Unique en el caso de un cliente solo de IPv6.
La red inalámbrica unificada de Cisco admite dos métodos de distribución multidifusión a los AP asociados al controlador. En ambos modos, el paquete multicast original de la red cableada se encapsula dentro de un paquete CAPWAP de Capa 3 enviado a través de la unidifusión CAPWAP o la multidifusión al AP. Dado que el tráfico está encapsulado en CAPWAP, los AP no tienen que estar en la misma VLAN que el tráfico del cliente. Aquí se comparan los dos métodos de distribución de multidifusión:
Modo Multicast-Unicast | Modo Multicast-Multicast | |
---|---|---|
Mecanismo de entrega | El controlador replica el paquete multicast y lo envía a cada AP en un túnel CAPWAP unicast | El controlador envía una copia del paquete multicast |
Modos de AP admitidos | FlexConnect y local | Sólo modo local |
Requiere ruteo de multidifusión de capa 3 en una red por cable | No | Yes |
Carga del controlador | Alto | Bajo |
Carga de red por cable | Alto | Bajo |
El modo multidifusión-multidifusión es la opción recomendada por motivos de escalabilidad y eficiencia del ancho de banda por cable.
Nota: Este paso sólo es absolutamente necesario para el controlador inalámbrico de la serie 2500, pero permite una transmisión multidifusión más eficaz y se recomienda para todas las plataformas de controlador.
Vaya a la pestaña "Controlador" bajo la página "General" y asegúrese de que el Modo de multidifusión AP esté configurado para utilizar el modo multidifusión y de que se haya configurado una dirección de grupo válida. La dirección de grupo es un grupo de multidifusión IPv4 y se recomienda que se encuentre en el intervalo 239.X.X.X-239.255.255.255, que se estudia para las aplicaciones de multidifusión privadas.
Nota: No utilice los rangos de direcciones 224.X.X.X, 239.0.0.X o 239.128.0.X para la dirección del grupo multicast. Las direcciones en estos rangos se superponen con las direcciones MAC locales del link e inundan todos los puertos del switch, incluso con la indagación IGMP habilitada.
Si la red cableada no está configurada correctamente para ofrecer la multidifusión CAPWAP entre el controlador y el modo AP o FlexConnect, y los AP se utilizarán para las WLANs conmutadas centralmente que soportan IPv6, se requiere el modo unidifusión.
Vaya a la pestaña Controller bajo la página General, y asegúrese de que el modo AP Multicast esté configurado para utilizar el modo Unicast.
Conecte un cliente compatible con IPv6 a la LAN inalámbrica. Valide que el cliente recibe una dirección IPv6 navegando a la pestaña Monitor y luego al menú Clientes.
No hay ninguna configuración específica para la movilidad IPv6 excepto para colocar los controladores en el mismo grupo de movilidad o dentro del mismo dominio de movilidad. Esto permite que un total de hasta 72 controladores participen en un dominio de movilidad, lo que proporciona una movilidad perfecta incluso para los campus más grandes.
Vaya a la pestaña Controlador > Grupos de Movilidad y agregue cada controlador por dirección MAC e dirección IP al grupo. Esto debe hacerse en todos los controladores del grupo de movilidad.
El controlador soporta la indagación MLDv1 para la multidifusión IPv6, lo que le permite realizar un seguimiento inteligente de los flujos de multidifusión y enviarlos a los clientes que los soliciten.
Nota: A diferencia de las versiones anteriores, la compatibilidad con el tráfico unidifusión IPv6 no exige que el "modo multidifusión global" se habilite en el controlador. La compatibilidad con el tráfico unidifusión IPv6 se habilita automáticamente.
Vaya a la página Controller tab > Multicast y Enable MLD Snooping para soportar el tráfico IPv6 multicast. Para habilitar la multidifusión IPv6, el modo multidifusión global del controlador también debe estar habilitado.
Nota: El modo multidifusión global, IGMP y la indagación MLD deben estar habilitados si se requieren aplicaciones de detección de igual a igual como Bonjour de Apple.
Para verificar que el tráfico de multidifusión IPv6 se está expandiendo, vaya a la pestaña Monitor y a la página Multicast. Observe que se enumeran los grupos de multidifusión IPv4 (IGMP) e IPv6 (MLD). Haga clic en el MGID para ver los clientes inalámbricos unidos a esa dirección de grupo.
Navegue hasta la pestaña Controller y luego IPv6 > RA Guard en el menú de la izquierda. Habilite IPv6 RA Guard en AP. La protección RA en el controlador no se puede inhabilitar. Además de la configuración de RA Guard, esta página también muestra cualquier cliente que se haya identificado como el envío de RAs.
Vaya a la ficha Seguridad, abra Listas de control de acceso y haga clic en Nuevo.
Ingrese un nombre único para la ACL, cambie el tipo de ACL a IPv6 y haga clic en Aplicar.
Haga clic en la nueva ACL que se creó en los pasos anteriores.
Haga clic en Agregar nueva regla, introduzca los parámetros deseados para la regla y haga clic en Aplicar. Deje el número de secuencia en blanco para colocar la regla al final de la lista. La opción "Dirección" de "Entrante" se utiliza para el tráfico procedente de la red inalámbrica y "Saliente" para el tráfico destinado a clientes inalámbricos. Recuerde que la última regla de una ACL es un deny-all implícito. Utilice una longitud de prefijo de 64 para hacer coincidir toda una subred IPv6 y una longitud de prefijo de 128 para restringir de forma exclusiva el acceso a una dirección individual.
Las ACL IPv6 se aplican por WLAN/SSID y se pueden utilizar en varias WLAN simultáneamente. Navegue hasta la pestaña WLANs y haga clic en el ID WLAN del SSID en cuestión para aplicar la ACL IPv6. Haga clic en la pestaña Advanced y cambie la ACL Override Interface para IPv6 al nombre ACL.
Configure la ACL de autenticación previa IPv4 e IPv6 para el servidor web. Esto permite el tráfico hacia y desde el servidor externo antes de que el cliente se autentique completamente.
Para obtener más información sobre el funcionamiento del acceso Web externo, refiérase a Ejemplo de Configuración de Autenticación Web Externa con Controladores LAN Inalámbricos.
Configure la WLAN de invitado navegando a la pestaña WLAN en la parte superior. Cree el SSID de invitado y utilice una política web de Capa 3. Las ACL de autenticación previa definidas en el paso 1 se seleccionan para IPv4 e IPv6. Marque la sección Over-ride Global Config y seleccione External en el cuadro desplegable de tipo Web Auth. Introduzca la dirección URL del servidor web. El nombre de host del servidor externo debe resolverse en IPv4 e IPv6 DNS.
Navegue hasta el menú de nivel superior Controller y haga clic en la opción IPv6 > Política de aceleración RA en el lado izquierdo. Active la Regulación de RA haciendo clic en la casilla de verificación.
Nota: Cuando se produce la Regulación de RA, sólo se permite pasar el primer router compatible con IPv6. Para las redes con varios prefijos IPv6 atendidos por diferentes routers, la regulación de RA debe ser inhabilitada.
Ajuste el período del acelerador y otras opciones únicamente según lo aconseje el TAC. Sin embargo, se recomienda el valor predeterminado para la mayoría de las implementaciones. Las diversas opciones de configuración de la política de aceleración de RA deben ajustarse teniendo en cuenta lo siguiente:
Los valores numéricos de "Permitir al menos" deben ser inferiores a "Permitir al máximo", que deben ser inferiores a "Máx. hasta".
La política del acelerador RA no debe utilizar un período de regulación superior a 1800 segundos, ya que ésta es la duración predeterminada de la mayoría de los RA.
A continuación se describe cada opción de Regulación de RA:
Período de aceleración: el período de tiempo durante el cual se produce la regulación. La regulación de RA sólo surte efecto después de que se alcance el límite "Máximo a través" para la VLAN.
Max Through (Pasar máximo): Este es el número máximo de RA por VLAN antes de que la aceleración se inicie. La opción "Sin límite" permite una cantidad ilimitada de RAs sin limitación.
Opción de intervalo: la opción de intervalo permite que el controlador actúe de forma diferente según el valor RFC 3775 establecido en la RA IPv6.
Passthrough (Paso a través de) - Este valor permite que cualquier RA con una opción de intervalo RFC3775 pase sin regulación.
Ignorar - Este valor hará que el regulador de artritis reumatoide trate los paquetes con la opción de intervalo como una RA regular y sujeto a regulación si es que están en vigor.
Throttle - Este valor hará que los RAs con la opción de intervalo siempre estén sujetos a limitación de velocidad.
Allow (Permitir al menos): el número mínimo de RA por router que se enviarán como multicast.
Allow At-most - El número máximo de RAs por router que se enviarán como multicast antes de que la regulación surta efecto. La opción "Sin límite" permitirá un número ilimitado de RA a través de ese router.
Vaya al menú de nivel superior del controlador y haga clic en IPv6 > Temporizadores de enlace de vecino en el menú de la izquierda.
Ajuste la vida útil, la vida útil alcanzable y la vida útil obsoleta según sea necesario. En el caso de implementaciones con clientes que son altamente móviles, se deben ajustar los temporizadores de un temporizador de direcciones obsoleto. Los valores recomendados son:
Tiempo de vida inactivo: 30 segundos
Vida útil alcanzable: 300 segundos
Duración del estado: 86400 segundos
Cada temporizador de duración hace referencia al estado en el que puede estar una dirección IPv6:
Tiempo de vida inactivo: el temporizador de inactividad especifica cuánto tiempo deben mantenerse las entradas de la memoria caché IPv6 si la interfaz de enlace ascendente del controlador se desactiva.
Tiempo de vida alcanzable - Este temporizador especifica cuánto tiempo se marcará una dirección IPv6 activa, lo que significa que recientemente se ha recibido tráfico de esta dirección. Una vez que este temporizador caduca, la dirección se mueve al estado "Stale".
Vida útil obsoleta: Este temporizador especifica cuánto tiempo deben mantenerse las direcciones IPv6 en la memoria caché que no se han visto dentro del "Tiempo de vida alcanzable". Después de esta vida útil, la dirección se quita de la tabla de enlace.
Asegúrese de que las funciones de Global VideoStream estén habilitadas en Controller. Consulte Solución Cisco Unified Wireless Network: Guía de implementación de VideoStream para obtener información sobre cómo habilitar VideoStream en la red 802.11a/g/n así como el SSID de WLAN.
Vaya a la pestaña Wireless en el controlador y, en el menú de la izquierda, elija Media Stream > Streams. Haga clic en Agregar nuevo para crear una nueva secuencia.
Asigne un nombre a la secuencia e introduzca las direcciones IPv6 inicial y final. Cuando se utiliza sólo una secuencia única, las direcciones inicial y final son iguales. Después de agregar las direcciones, haga clic en Aplicar para crear la secuencia.
Algunas implementaciones de pila de red IPv6 del cliente no se anuncian correctamente al entrar en la red y, por lo tanto, el controlador no realiza la detección adecuada de su dirección para colocarla en la tabla de enlace vecina. Las direcciones que no estén presentes en la tabla de enlace de vecinos se bloquean según la función de protección de origen de IPv6. Para permitir que estos clientes pasen tráfico, estas opciones deben configurarse:
Desactive la función IPv6 Source Guard a través de la CLI:
config network ip-mac-binding disable
Habilite el Reenvío de Solicitud de Vecino Multicast a través de la CLI:
config ipv6 ns-mcast-fwd enable
Ejecute estos comandos debug tanto en el controlador de anclaje como en el controlador externo:
debug client
debug mobility handoff enable
debug mobility packet enable
Resultados de depuración en controlador de anclaje:
00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) State Update from Mobility-Complete to Mobility-Incomplete 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Setting handles to 0x00000000 00:21:6a:a7:4f:ee pemApfDeleteMobileStation2: APF_MS_PEM_WAIT_L2_AUTH_COMPLETE = 0. 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Deleted mobile LWAPP rule on AP [04:fe:7f:49:03:30] 00:21:6a:a7:4f:ee Updated location for station old AP 04:fe:7f:49:03:30-1, new AP 00:00:00:00:00:00-0 00:21:6a:a7:4f:ee Stopping deletion of Mobile Station: (callerId: 42) 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) State Update from Mobility-Incomplete to Mobility-Complete, mobility role=Anchor, client state=APF_MS_STATE_ASSOCIATED 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Change state to RUN (20) last state RUN (20) 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Reached PLUMBFASTPATH: from line 4968 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Adding Fast Path rule type = Airespace AP Client on AP 00:00:00:00:00:00, slot 0, interface = 13, QOS = 0 IPv4 ACL ID = 255, IPv6 ACL ID = 255, 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 7006 Local Bridging Vlan = 20, Local Bridging intf id = 13 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255) 00:21:6a:a7:4f:ee 0.0.0.0 Removed NPU entry. 00:21:6a:a7:4f:ee Set symmetric mobility tunnel for 00:21:6a:a7:4f:ee as in Anchor role 00:21:6a:a7:4f:ee 0.0.0.0 Added NPU entry of type 1, dtlFlags 0x1 00:21:6a:a7:4f:ee Pushing IPv6: fe80:0000:0000:0000: 3057:534d:587d:73ae , and MAC: 00:21:6A:A7:4F:EE , Binding to Data Plane. SUCCESS !! 00:21:6a:a7:4f:ee Pushing IPv6: 2001:0db8:0000:0020: 3057:534d:587d:73ae , and MAC: 00:21:6A:A7:4F:EE , Binding to Data Plane. SUCCESS !! 00:21:6a:a7:4f:ee 0.0.0.0, VLAN Id 20 Not sending gratuitous ARP 00:21:6a:a7:4f:ee Copy AP LOCP - mode:0 slotId:0, apMac 0x0:0:0:0:0:0 00:21:6a:a7:4f:ee Copy WLAN LOCP EssIndex:3 aid:0 ssid: Roam 00:21:6a:a7:4f:ee Copy Security LOCP ecypher:0x0 ptype:0x2, p:0x0, eaptype:0x6 w:0x1 aalg:0x0, PMState: RUN 00:21:6a:a7:4f:ee Copy 802.11 LOCP a:0x0 b:0x0 c:0x0 d:0x0 e:0x0 protocol2:0x5 statuscode 0, reasoncode 99, status 3 00:21:6a:a7:4f:ee Copy CCX LOCP 4 00:21:6a:a7:4f:ee Copy e2e LOCP 0x1 00:21:6a:a7:4f:ee Copy MobilityData LOCP status:2, anchorip:0xac14e2c6 00:21:6a:a7:4f:ee Copy IPv6 LOCP: fe80::3057:534d:587d:73ae
Resultados de depuración en controlador externo:
00:21:6a:a7:4f:ee Adding mobile on LWAPP AP f0:25:72:3c:0f:20(1) 00:21:6a:a7:4f:ee Reassociation received from mobile on AP f0:25:72:3c:0f:20 00:21:6a:a7:4f:ee 0.0.0.0 START (0) Changing IPv4 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:1697) 00:21:6a:a7:4f:ee 0.0.0.0 START (0) Changing IPv6 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:1864) 00:21:6a:a7:4f:ee Applying site-specific Local Bridging override for station 00:21:6a:a7:4f:ee - vapId 3, site 'default-group', interface 'client-b1' 00:21:6a:a7:4f:ee Applying Local Bridging Interface Policy for station 00:21:6a:a7:4f:ee - vlan 25, interface id 12, interface 'client-b1' 00:21:6a:a7:4f:ee processSsidIE statusCode is 0 and status is 0 00:21:6a:a7:4f:ee processSsidIE ssid_done_flag is 0 finish_flag is 0 00:21:6a:a7:4f:ee STA - rates (8): 140 18 152 36 176 72 96 108 0 0 0 0 0 0 0 0 *apfMsConnTask_4: Jan 22 20:37:45.370: 00:21:6a:a7:4f:ee suppRates statusCode is 0 and gotSuppRatesElement is 1 00:21:6a:a7:4f:ee Processing RSN IE type 48, length 22 for mobile 00:21:6a:a7:4f:ee 00:21:6a:a7:4f:ee 0.0.0.0 START (0) Initializing policy 00:21:6a:a7:4f:ee 0.0.0.0 START (0) Change state to AUTHCHECK (2) last state AUTHCHECK (2) 00:21:6a:a7:4f:ee 0.0.0.0 AUTHCHECK (2) Change state to 8021X_REQD (3) last state 8021X_REQD (3) 00:21:6a:a7:4f:ee 0.0.0.0 8021X_REQD (3) DHCP Not required on AP f0:25:72:3c:0f:20 vapId 3 apVapId 3for this client 00:21:6a:a7:4f:ee Not Using WMM Compliance code qosCap 00 00:21:6a:a7:4f:ee 0.0.0.0 8021X_REQD (3) Plumbed mobile LWAPP rule on AP f0:25:72:3c:0f:20 vapId 3 apVapId 3 00:21:6a:a7:4f:ee apfMsAssoStateInc 00:21:6a:a7:4f:ee apfPemAddUser2 (apf_policy.c:268) Changing state for mobile 00:21:6a:a7:4f:ee on AP f0:25:72:3c:0f:20 from Idle to Associated 00:21:6a:a7:4f:ee Scheduling deletion of Mobile Station: (callerId: 49) in 1800 seconds 00:21:6a:a7:4f:ee Sending Assoc Response to station on BSSID f0:25:72:3c:0f:20 (status 0) ApVapId 3 Slot 1 00:21:6a:a7:4f:ee apfProcessAssocReq (apf_80211.c:6290) Changing state for mobile 00:21:6a:a7:4f:ee on AP f0:25:72:3c:0f:20 from Associated to Associated <…SNIP…> 00:21:6a:a7:4f:ee 0.0.0.0 8021X_REQD (3) Change state to L2AUTHCOMPLETE (4) last state L2AUTHCOMPLETE (4) 00:21:6a:a7:4f:ee 0.0.0.0 L2AUTHCOMPLETE (4) DHCP Not required on AP f0:25:72:3c:0f:20 vapId 3 apVapId 3for this client 00:21:6a:a7:4f:ee Not Using WMM Compliance code qosCap 00 00:21:6a:a7:4f:ee 0.0.0.0 L2AUTHCOMPLETE (4) Plumbed mobile LWAPP rule on AP f0:25:72:3c:0f:20 vapId 3 apVapId 3 00:21:6a:a7:4f:ee 0.0.0.0 L2AUTHCOMPLETE (4) Change state to DHCP_REQD (7) last state DHCP_REQD (7) 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) pemAdvanceState2 5253, Adding TMP rule 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Adding Fast Path rule type = Airespace AP - Learn IP address on AP f0:25:72:3c:0f:20, slot 1, interface = 13, QOS = 0 IPv4 ACL ID = 255, IP 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 7006 Local Bridging Vlan = 25, Local Bridging intf id = 12 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255) 00:21:6a:a7:4f:ee Stopping retransmission timer for mobile 00:21:6a:a7:4f:ee 00:21:6a:a7:4f:ee 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0 00:21:6a:a7:4f:ee Sent an XID frame 00:21:6a:a7:4f:ee Username entry () already exists in name table, length = 253 00:21:6a:a7:4f:ee Username entry () created in mscb for mobile, length = 253 00:21:6a:a7:4f:ee Applying post-handoff policy for station 00:21:6a:a7:4f:ee - valid mask 0x1000 00:21:6a:a7:4f:ee QOS Level: -1, DSCP: -1, dot1p: -1, Data Avg: -1, realtime Avg: -1, Data Burst -1, Realtime Burst -1 00:21:6a:a7:4f:ee Session: -1, User session: -1, User elapsed -1 Interface: N/A, IPv4 ACL: N/A, IPv6 ACL: 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Change state to DHCP_REQD (7) last state DHCP_REQD (7) 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) pemCreateMobilityState 6370, Adding TMP rule 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Replacing Fast Path rule type = Airespace AP - Learn IP address on AP f0:25:72:3c:0f:20, slot 1, interface = 13, QOS = 0 IPv4 ACL ID = 255, 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 7006 Local Bridging Vlan = 25, Local Bridging intf id = 12 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255) 00:21:6a:a7:4f:ee Scheduling deletion of Mobile Station: (callerId: 55) in 1800 seconds 00:21:6a:a7:4f:ee Pushing IPv6: fe80:0000:0000:0000: 3057:534d:587d:73ae , and MAC: 00:21:6A:A7:4F:EE , Binding to Data Plane. SUCCESS !! 00:21:6a:a7:4f:ee apfMsRunStateInc 00:21:6a:a7:4f:ee 0.0.0.0 DHCP_REQD (7) Change state to RUN (20) last state RUN (20) 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Reached PLUMBFASTPATH: from line 5776 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Change state to RUN (20) last state RUN (20) 00:21:6a:a7:4f:ee Pushing IPv6: 2001:0db8:0000:0020: 3057:534d:587d:73ae , and MAC: 00:21:6A:A7:4F:EE , Binding to Data Plane. SUCCESS !! 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) State Update from Mobility-Incomplete to Mobility-Complete, mobility role=Foreign, client state=APF_MS_STATE_ASSOCIATED 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Change state to RUN (20) last state RUN (20) 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Reached PLUMBFASTPATH: from line 4968 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Replacing Fast Path rule type = Airespace AP Client on AP f0:25:72:3c:0f:20, slot 1, interface = 13, QOS = 0 IPv4 ACL ID = 255, IPv6 ACL ID = 25 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 7006 Local Bridging Vlan = 25, Local Bridging intf id = 12 00:21:6a:a7:4f:ee 0.0.0.0 RUN (20) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255) 00:21:6a:a7:4f:ee 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0 00:21:6a:a7:4f:ee Set symmetric mobility tunnel for 00:21:6a:a7:4f:ee as in Foreign role 00:21:6a:a7:4f:ee 0.0.0.0 Added NPU entry of type 1, dtlFlags 0x1 00:21:6a:a7:4f:ee Pushing IPv6: fe80:0000:0000:0000: 3057:534d:587d:73ae , and MAC: 00:21:6A:A7:4F:EE , Binding to Data Plane. SUCCESS !! 00:21:6a:a7:4f:ee Pushing IPv6: 2001:0db8:0000:0020: 3057:534d:587d:73ae , and MAC: 00:21:6A:A7:4F:EE , Binding to Data Plane. SUCCESS !! 00:21:6a:a7:4f:ee Copy AP LOCP - mode:0 slotId:1, apMac 0xf0:25:72:3c:f:20 00:21:6a:a7:4f:ee Copy WLAN LOCP EssIndex:3 aid:1 ssid: Roam 00:21:6a:a7:4f:ee Copy Security LOCP ecypher:0x0 ptype:0x2, p:0x0, eaptype:0x6 w:0x1 aalg:0x0, PMState: RUN 00:21:6a:a7:4f:ee Copy 802.11 LOCP a:0x0 b:0x0 c:0x0 d:0x0 e:0x0 protocol2:0x7 statuscode 0, reasoncode 99, status 3 00:21:6a:a7:4f:ee Copy CCX LOCP 4 00:21:6a:a7:4f:ee Copy e2e LOCP 0x1 00:21:6a:a7:4f:ee Copy MobilityData LOCP status:3, anchorip:0xac14e2c5 00:21:6a:a7:4f:ee Copy IPv6 LOCP: fe80::3057:534d:587d:73ae 00:21:6a:a7:4f:ee Copy IPv6 LOCP: 2001:db8:0:20:3057:534d:587d:73ae
Show ipv6 neighbor-binding summary
Debug ipv6 neighbor-binding filter client
enable
Debug ipv6 neighbor-binding filter errors enable
A: ¿Cuál es el tamaño óptimo del prefijo IPv6 para limitar el dominio de broadcast?
R: Aunque una subred IPv6 se puede subdividir debajo de un /64, esta configuración interrumpirá el SLAAC y causará problemas con la conectividad del cliente. Si se necesita segmentación para reducir el número de hosts, la función Grupos de Interfaz se puede utilizar para balancear la carga de los clientes entre diferentes VLAN de back-end, cada una usando un prefijo IPv6 diferente.
A: ¿Hay alguna limitación de escalabilidad a la hora de admitir clientes IPv6?
R: La principal limitación de escalabilidad para el soporte del cliente IPv6 es la tabla de enlace de vecinos que realiza un seguimiento de todas las direcciones IPv6 del cliente inalámbrico. Esta tabla se escala por plataforma de controlador para soportar el número máximo de clientes multiplicado por ocho (el número máximo de direcciones por cliente). La adición de la tabla de enlace IPv6 puede aumentar el uso de memoria del controlador aproximadamente un 10-15% con carga completa, dependiendo de la plataforma.
Controlador inalámbrico | Número máximo de clientes | Tamaño de tabla de enlace de vecino IPv6 |
---|---|---|
2500 | 500 | 4,000 |
5500 | 7,000 | 56,000 |
WiSM2 | 15,000 | 120,000 |
A: ¿Cuál es el impacto de las funciones de IPv6 en la CPU y la memoria del controlador?
R: El impacto es mínimo, ya que la CPU tiene varios núcleos para procesar el plano de control. Cuando se probó con el número máximo de clientes admitidos, cada uno con 8 direcciones IPv6, el uso de la CPU fue inferior al 30% y el uso de memoria inferior al 75%.
A: ¿Se puede inhabilitar la compatibilidad con el cliente IPv6?
R: Para los clientes que desean habilitar sólo IPv4 en su red y bloquear IPv6, se puede utilizar y aplicar una ACL IPv6 de tráfico denegado total por WLAN.
A: ¿Es posible tener una WLAN para IPv4 y otra para IPv6?
R: No es posible tener el mismo nombre de SSID y tipo de seguridad para dos WLAN diferentes que funcionan en el mismo AP. Para la segmentación de clientes IPv4 de clientes IPv6, se deben crear dos WLAN. Cada WLAN debe configurarse con una ACL que bloquee todo el tráfico IPv4 o IPv6 respectivamente.
A: ¿Por qué es importante admitir varias direcciones IPv6 por cliente?
R: Los clientes pueden tener varias direcciones IPv6 por interfaz que pueden ser estáticas, SLAAC o DHCPv6 asignadas además de tener siempre una dirección local de link autoasignada. Los clientes también pueden tener direcciones adicionales usando diferentes prefijos IPv6.
A: ¿Qué son las direcciones privadas IPv6 y por qué es importante realizar un seguimiento?
R: Las direcciones privadas (también conocidas como temporales) son generadas aleatoriamente por el cliente cuando la asignación de dirección SLAAC está en uso. Estas direcciones a menudo se rotan a una frecuencia de aproximadamente un día, para evitar la rastreabilidad del host que vendría de usar el mismo postfijo del host (últimos 64 bits) en todo momento. Es importante realizar un seguimiento de estas direcciones privadas con fines de auditoría, como el seguimiento de la infracción de los derechos de autor. Cisco NCS registra todas las direcciones IPv6 en uso por cada cliente e históricamente las registra cada vez que el cliente avanza o establece una nueva sesión. Estos registros se pueden configurar en NCS para que se conserven hasta un año.