Add IPv6 support to network drivers
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 30/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Tranquilo
- Stack tecnológico
- docker, powershell
- Área
- networking, operating-systems
Línea de trabajo
No se mencionan archivos fuente ni pruebas. Empieza reproduciendo los comandos documentados de PowerShell Docker en la branch enlazada y, después, inspecciona la ruta de red de HNS para la asignación de subredes IPv6, la configuración del adaptador, la política del firewall y la configuración IPv4-only. La tarea estaría terminada cuando existan implementaciones y pruebas definidas para el comportamiento IPv6 solicitado en los controladores de red relevantes.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Hi,
moby / libnetwork maintainer here.
As the OMB memorandum M-21-07 will come into force in Sep. 2025, we started working on IPv6 improvements for Linux containers and we’ll need to add IPv6 support to Windows containers before that deadline. Since the API documentation for HNS doesn’t mention IPv6 limitations, I started playing with the API to see what roadblockers I could find.
I’m opening this ticket to document what I found and make feature requests. All the docker commands below are run against this branch: https://github.com/moby/moby/pull/48285.
So far, I only tested the nat driver, but we’ll need similar improvements for other drivers.
Here’s a TL;DR list of Feature Requests:
- Dynamic IPv6 subnet allocations
- Automatically add IPv6 address to containers’ adapters
- Automatically add the required firewall policies to get outbound connectivity
- Add a parameter to HNSNetwork to disable IPv4 (make networks IPv6-only)
Create an IPv6 network
So far, I’m able to create a network with static IPv6 subnet, but unlike IPv4, HNS won’t dynamically allocate IPv6 subnets:
# Doesn't work:
> docker network create -d nat --ipv6 testnet-ipv6
Error response from daemon: failed during hnsCallRawResponse: hnsCall failed in Win32: Element not found. (0x490)
# Works properly
> docker network create -d nat --ipv6 --subnet fdf7:50::/64 testnet-ipv6
Run a container attached to an IPv6 network
Container's IP address isn't automatically added to its interface:
# Create a container attached to that network
> docker run --rm -it --name=c0 --network=testnet-ipv6 mcr.microsoft.com/windows/servercore:ltsc2022 powershell
> docker inspect c0
# From the container's terminal:
> Get-NetIPConfiguration
InterfaceAlias : Ethernet
InterfaceIndex : 4
InterfaceDescription : Microsoft Hyper-V Network Adapter
IPv4Address : 172.24.22.190
IPv6DefaultGateway :
IPv4DefaultGateway : 172.24.16.1
DNSServer : 172.24.16.1
192.168.1.254
> New-NetIPAddress -InterfaceIndex 4 -IPAddress fdf7:50::14 -PrefixLength 64 -DefaultGateway fdf7:50::1
> Get-NetIPAddress -AddressFamily IPv6 | Foreach IPAddress
fe80::9be4:d1d6:192f:9941%4
fdf7:50::14
Ping the host from the container (and vice-versa)
Pinging the host from the container doesn't work (although the reverse does). It seems there's a missing firewall policy to allow outbound connectivity:
# From the container, ping the host:
$ ping -n 1 -6 fdf7:50::1
Pinging fdf7:50::1 with 32 bytes of data:
Request timed out.
Ping statistics for fdf7:50::1:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
# Can't ping the host, but NDP seems to work correctly
$ Get-NetNeighbor | findstr "fdf7:50::1"
4 fdf7:50::1 00-15-5D-F4-11-23 Reachable ActiveStore
# From the host, ping the container:
$ ping -n 1 -6 fdf7:50::14
Pinging fdf7:50::14 with 32 bytes of data:
Reply from fdf7:50::14: time<1ms
Ping statistics for fdf7:50::14:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
And taking a look with pktmon:
[04]0000.0000::2024-08-02 08:26:51.926095500 [Microsoft-Windows-PktMon] Drop: PktGroupId 1125899906842625, PktNumber 1, Appearance 16, Direction Rx , Type IP , Component 187, Filter 1, DropReason ICMP: inspection drop , DropLocation 0xE00041C7, OriginalSize 80, LoggedSize 80
Drop: ip: fdf7:50::1 > fdf7:50::14: ICMP6, echo request, seq 11, length 40
[04]0000.0000::2024-08-02 08:26:51.926099700 [Microsoft-Windows-PktMon] Duplicate Drop: PktGroupId 1125899906842625, PktNumber 1, Appearance 17, Direction Rx , Type IP , Component 187, Filter 1, DropReason INET: transport endpoint was not found , DropLocation 0xE0004704, OriginalSize 80, LoggedSize 80
Duplicate Drop: ip: fdf7:50::14 > fdf7:50::1: ICMP6, echo request, seq 11, length 40
[04]0000.0000::2024-08-02 08:26:51.926102500 [Microsoft-Windows-PktMon] Duplicate Drop: PktGroupId 1125899906842625, PktNumber 1, Appearance 18, Direction Rx , Type IP , Component 187, Filter 1, DropReason Inspection drop , DropLocation 0xE0004134, OriginalSize 80, LoggedSize 80
Duplicate Drop: ip: fdf7:50::14 > fdf7:50::1: ICMP6, echo request, seq 11, length 40
...
[05]48E0.8ACC::2024-08-02 08:26:57.026926700 [Microsoft-Windows-PktMon] Component 187, Type 11, Name tcpip.sys, TCP/IPv6 - L3/L4
[05]48E0.8ACC::2024-08-02 08:26:57.026927300 [Microsoft-Windows-PktMon] Property: Component 187, IP Address = fe80::e232:bea9:7bb6:84a5
[05]48E0.8ACC::2024-08-02 08:26:57.026927600 [Microsoft-Windows-PktMon] Property: Component 187, IP Address = fdf7:50::1
[05]48E0.8ACC::2024-08-02 08:26:57.026928000 [Microsoft-Windows-PktMon] Property: Component 187, Compartment ID = 1
[05]48E0.8ACC::2024-08-02 08:26:57.026928600 [Microsoft-Windows-PktMon] Property: Component 187, IpIfIndex = 72
- Lenguaje dominante
- PowerShell
- Estrellas
- 552
- Forks
- 75
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/Windows-Containers
-
enhancement triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
microsoft/Windows-Containers#630 · 6 comentarios ·
-
bug triage
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
microsoft/Windows-Containers#655 · 3 comentarios ·
-
enhancement triage
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
microsoft/Windows-Containers#653 · 1 comentario ·
-
enhancement triage
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
microsoft/Windows-Containers#652 · 1 comentario ·
-
CimFS-backed overlay mount performance parity with Linux overlayfs for container image layersAbiertoenhancement triage
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
microsoft/Windows-Containers#651 · 1 comentario ·
Todos los issues de microsoft/Windows-Containers
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
golang/go#82032 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
SagerNet/sing-openvpn#11 ·
-
TlsSocketController.claim() leaks a "secureConnect" listener per request on a kept-alive socketAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
mswjs/interceptors#859 ·
Los mantenedores suelen responder en 1 día
-
ws_bridge: stripping format=evr for matchmaker connections can concatenate the path and queryAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
EchoTools/nevr-runtime#116 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
FujiNetWIFI/fujinet-firmware#1834 ·
Los mantenedores suelen responder en 1 día