Kẻ tấn công có thể làm lộ VPN dựa trên định tuyến

 (leviathansecurity.com)
3 điểm bởi GN⁺ 2024-05-07 | 1 bình luận | Chia sẻ qua WhatsApp
  • TunnelVision (CVE-2024-3661) lợi dụng chức năng sẵn có của DHCP để chuyển hướng lưu lượng của người dùng ra ngoài đường hầm VPN, khiến các gói tin không được mã hóa bởi VPN
  • Kẻ tấn công có thể chèn các tuyến cụ thể hơn bằng DHCP option 121 để tạo đường đi được ưu tiên hơn giao diện ảo của VPN, từ đó đẩy lưu lượng qua giao diện vật lý
  • Cuộc tấn công khả thi nếu mục tiêu chấp nhận lease DHCP do kẻ tấn công kiểm soát và client triển khai option 121; trong thử nghiệm, Windows, Linux, iOS và macOS bị ảnh hưởng, còn Android thì không
  • Kênh điều khiển VPN vẫn được duy trì nên người dùng vẫn thấy trạng thái đang kết nối; trong các trường hợp quan sát được, kill switch cũng không ngăn được rò rỉ lưu lượng
  • Network namespace của Linux có thể là giải pháp mạnh, nhưng biện pháp giảm thiểu dựa trên tường lửa có thể tạo ra từ chối dịch vụ có chọn lọc và side channel suy đoán đích đến của lưu lượng

TunnelVision tạo ra hiện tượng VPN decloaking

  • TunnelVision là một kỹ thuật mạng buộc lưu lượng của người dùng đi ra ngoài đường hầm bằng cách vượt qua lớp bao gói của VPN
  • Kẻ tấn công có thể dùng DHCP (Dynamic Host Configuration Protocol) để khiến các gói tin mục tiêu được truyền đi mà không được VPN mã hóa
  • Vì kênh điều khiển VPN vẫn được giữ nguyên, người dùng vẫn tưởng như đang kết nối VPN, và hiệu ứng này được gọi là decloaking
  • Kỹ thuật này có thể đã khả thi từ tận năm 2002, và sau khi công bố, đã xác nhận có các nghiên cứu trước đó về DHCP option 121 và tác động tới VPN ít nhất từ năm 2015

Vì sao định tuyến VPN trở thành bề mặt tấn công

  • VPN tạo một đường hầm cho lưu lượng giữa thiết bị máy chủ và máy chủ ở mạng khác, còn client VPN sẽ mã hóa và giải mã lưu lượng tại giao diện mạng ảo
  • Cấu hình gửi toàn bộ lưu lượng qua VPN được gọi là full-tunnel VPN, còn cấu hình có ngoại lệ như mạng cục bộ được gọi là split-tunnel VPN
  • Do VPN phải duy trì kết nối với máy chủ, nên cần có tuyến ngoại lệ để lưu lượng hướng tới IP máy chủ VPN đi qua giao diện vật lý
  • Bảng định tuyến quyết định đường đi của lưu lượng theo đích, và trong hầu hết network stack, CIDR prefix length cụ thể hơn sẽ có ưu tiên cao hơn
    • Tuyến /32 được ưu tiên hơn /24 hoặc /0
    • Nhiều full-tunnel VPN gửi lưu lượng tới giao diện VPN bằng 0.0.0.0/0 hoặc hai tuyến /1

Chèn tuyến bằng DHCP option 121

  • DHCP động cấp lease địa chỉ IP cho thiết bị trong mạng cục bộ, đồng thời truyền các cấu hình như default gateway và máy chủ DNS qua options
  • Luồng thông thường là client phát DHCPDISCOVER theo kiểu broadcast, sau đó máy chủ đề xuất một lease có thời hạn bằng DHCPOFFER
  • DHCP option 121, được giới thiệu trong RFC 3442, là tính năng classless static routes cho phép máy chủ DHCP thêm các tuyến tĩnh vào bảng định tuyến của client
  • Option 121 không cho phép máy chủ DHCP chỉ định trực tiếp thiết bị giao diện mạng sẽ cài đặt tuyến đó
    • Máy chủ DHCP chỉ định dải CIDR và router
    • Client ngầm chọn giao diện đang dùng để liên lạc với máy chủ DHCP làm giao diện cho tuyến đó
  • Vì hành vi này, lưu lượng đi theo các tuyến bị chèn có thể thoát ra qua giao diện mạng vật lý đang liên lạc với máy chủ DHCP, thay vì giao diện ảo của VPN

Điều kiện và cách thức thực hiện tấn công

  • Tấn công TunnelVision cần hai điều kiện
    • Máy chủ mục tiêu phải chấp nhận lease từ máy chủ DHCP do kẻ tấn công kiểm soát
    • DHCP client của máy chủ mục tiêu phải triển khai DHCP option 121
  • Kẻ tấn công ở cùng mạng có thể trở thành máy chủ DHCP của mục tiêu theo nhiều cách
    • Thực hiện tấn công DHCP starvation vào máy chủ DHCP thật rồi phản hồi các client mới
    • Trả lời trước broadcast DHCPDISCOVER để lợi dụng hành vi chọn first-offer của DHCP client
    • Chặn lưu lượng giữa máy chủ DHCP thật và client bằng ARP spoofing rồi chờ gia hạn lease
  • Kẻ tấn công chạy máy chủ DHCP trên cùng mạng với người dùng VPN mục tiêu và đặt chính mình làm gateway
  • Sau đó dùng DHCP option 121 để thêm các tuyến tùy ý vào bảng định tuyến của người dùng VPN, chèn các tuyến cụ thể hơn /0 của VPN để chúng được ưu tiên hơn giao diện ảo của VPN
    • Có thể thiết lập nhiều tuyến /1 để tái tạo quy tắc toàn lưu lượng 0.0.0.0/0 mà đa số VPN sử dụng
    • Kẻ tấn công có thể chọn địa chỉ IP nào sẽ đi qua đường hầm VPN và địa chỉ nào sẽ đi qua giao diện đang liên lạc với máy chủ DHCP của kẻ tấn công
  • Cách này cũng áp dụng được với kết nối VPN đã thiết lập sẵn; nếu đặt thời gian lease DHCP ngắn, có thể buộc bảng định tuyến được cập nhật thường xuyên hơn

PoC và kịch bản thử nghiệm

  • Tài liệu công khai gồm có
  • Môi trường thử nghiệm được cấu hình để thể hiện nhiều kịch bản tấn công khác nhau
    • Kẻ tấn công đã xâm nhập máy chủ DHCP hoặc access point
    • Quản trị viên độc hại trực tiếp sở hữu và cấu hình hạ tầng
    • Kẻ tấn công đặt một wireless AP evil twin tại địa điểm vật lý như quán cà phê hoặc văn phòng
    • Sau khi ArcaneTrickster được công bố trong tương lai, cũng có thể mô phỏng kẻ tấn công là host lân cận trong cùng LAN nhưng không ở vị trí mạng đặc quyền

Hệ điều hành và VPN bị ảnh hưởng

  • Trong thử nghiệm, các hệ điều hành triển khai DHCP client theo đặc tả RFC và hỗ trợ tuyến DHCP option 121 đều bị ảnh hưởng
    • Đã quan sát ảnh hưởng trên: Windows, Linux, iOS, macOS
    • Ngoại lệ: Android không bị ảnh hưởng vì không hỗ trợ DHCP option 121
  • Các VPN chỉ dựa vào quy tắc định tuyến để bảo vệ lưu lượng của máy chủ là dễ bị tổn thương
  • Ngay cả quản trị viên hệ thống tự vận hành máy chủ VPN cũng có thể dễ bị ảnh hưởng nếu chưa harden cấu hình VPN client
  • Độ mạnh của thuật toán mã hóa không ảnh hưởng đến vấn đề này
    • TunnelVision không phá vỡ chính các giao thức VPN như WireGuard, OpenVPN hay IPsec
    • Nó thay đổi cấu hình định tuyến của network stack hệ điều hành để người dùng không còn đi qua đường hầm VPN nữa

Bản vá và biện pháp giảm thiểu

  • Network namespace của Linux có thể khắc phục hoàn toàn hành vi này
    • Tài liệu WireGuard cho thấy cách xử lý lưu lượng ứng dụng phải dùng VPN trong một namespace riêng, sau đó chuyển sang namespace khác có giao diện vật lý
    • Chưa rõ liệu Windows, macOS và các hệ điều hành khác có giải pháp vững chắc ở cùng mức độ hay không
  • Một số nhà cung cấp VPN dùng biện pháp giảm thiểu bằng cách chặn toàn bộ lưu lượng vào/ra trên giao diện vật lý bằng quy tắc tường lửa
    • Cần có ngoại lệ cho DHCP và IP máy chủ VPN để duy trì LAN và kết nối tới máy chủ VPN
    • Cũng có thể chỉ cho phép DHCP và giao thức VPN bằng deep packet inspection, nhưng điều này có thể gây hao hụt hiệu năng
  • Biện pháp giảm thiểu bằng tường lửa tạo ra từ chối dịch vụ có chọn lọc với lưu lượng dùng các tuyến DHCP và bổ sung side channel
    • Kẻ tấn công có thể phân tích thay đổi về lưu lượng VPN đã mã hóa để chứng minh thống kê rằng người dùng mục tiêu có đang gửi lưu lượng tới một đích cụ thể hay không
    • Có thể đối chiếu với danh sách định sẵn, thực hiện chặn có chọn lọc như một cơ chế kiểm duyệt, hoặc dùng chặn không gian IP như tìm kiếm nhị phân để tìm kết nối hiện tại trong thời gian logarit
  • Cũng có thể bỏ qua option 121 khi đang dùng VPN, nhưng tính năng này có thể cần thiết cho kết nối mạng hợp lệ nên có thể gây lỗi kết nối
    • Nếu biện pháp này là tùy chọn, kẻ tấn công có thể từ chối truy cập mạng để buộc VPN hoặc người dùng bật lại option 121
  • Hotspot hoặc VM cũng có thể giúp giảm thiểu
    • LAN được khóa bằng mật khẩu do thiết bị di động điều khiển có thể giúp ngăn kẻ tấn công truy cập mạng cục bộ
    • VM hoạt động tương tự nếu bộ điều hợp mạng không ở bridged mode

Việc cần làm với người dùng và nhà vận hành

  • Với lưu lượng nhạy cảm, nên tránh dùng mạng không đáng tin cậy; nếu không thể tránh, hãy dùng nhà cung cấp VPN có biện pháp giảm thiểu hiệu quả với TunnelVision
  • Ngay cả khi xảy ra VPN decloak, phần lớn dữ liệu người dùng vẫn không hiển thị với kẻ tấn công trong mạng cục bộ nếu truy cập website HTTPS, nhưng đích đến và giao thức vẫn có thể bị lộ
  • Khi dùng VPN doanh nghiệp tại quán cà phê, khách sạn, sân bay..., quản trị mạng cần cảnh báo rủi ro và hướng dẫn tránh dùng các mạng này nếu có thể
    • Nếu điều đó không thực tế, nên hướng dẫn dùng VPN đã áp dụng biện pháp giảm thiểu hoặc bản vá
    • Cũng có thể dùng hotspot đáng tin cậy rồi mới kết nối VPN, hoặc chạy VPN bên trong VM nhận lease từ một máy chủ DHCP ảo
  • Các công ty vận hành mạng riêng hoặc site-to-site VPN cần kiểm tra switch và bật các tính năng bảo vệ Layer 2 như DHCP snooping và bảo vệ ARP
    • Các biện pháp này giúp giảm máy chủ DHCP rogue nhưng không loại bỏ được kịch bản quản trị viên độc hại
    • Áp dụng HTTPS hoặc giao thức mã hóa khác cho tài nguyên nội bộ cũng giúp ngăn rò rỉ dữ liệu của người dùng VPN truy cập từ mạng không đáng tin cậy
  • Nhà cung cấp VPN có thể thêm tính năng tường lửa vào client để chặn các gói outbound đi ra giao diện mạng, nhưng khi đó người dùng sẽ không thể tương tác với tài nguyên mạng cục bộ
  • VPN client full-tunnel cho Linux nên cân nhắc cô lập bằng network namespace
  • Những người bảo trì hệ điều hành nên xem xét bổ sung hoặc tăng cường các tính năng liên quan tới network namespace trên các hệ điều hành ngoài Linux
  • Một thư viện hạ tầng đối kháng tên là ArcaneTrickster đang được phát triển để phục vụ nghiên cứu bảo mật LAN và trình diễn tấn công thực tế, và dự kiến sẽ được công bố sau

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-05-07
Ý kiến trên Hacker News

  • Đây chỉ là một biến thể nhẹ của cuộc tấn công PoisonTap của Samy Kamkar năm 2016. Nó làm điều tương tự bằng adapter mạng USB/Thunderbolt; nếu cắm vào thiết bị nạn nhân và quảng bá hai tuyến cụ thể hơn như 0.0.0.0/1 và 128.0.0.0/1, nó có thể ưu tiên hơn các giao diện hệ thống khác bất kể thứ tự giao diện, và lấy toàn bộ lưu lượng: https://github.com/samyk/poisontap
    Có lẽ còn có các tiền lệ khác, nhưng đây là một ví dụ rất nổi tiếng. Tiêu đề bài viết nói rằng mọi VPN client đều bị ảnh hưởng, nhưng như chính nội dung cũng thừa nhận, nhiều VPN client thiết lập các quy tắc tường lửa để chặn lưu lượng đi/đến qua giao diện vật lý
    Các VPN quảng bá khả năng ẩn danh, hoặc nơi việc ẩn danh đó là quan trọng, nhìn chung có xu hướng triển khai điều này. Có lẽ nhiều thiết lập không được bật theo mặc định, nhưng sẽ hữu ích hơn nếu bài viết ghi lại bao nhiêu phần trăm các giải pháp VPN cá nhân/thương mại/doanh nghiệp lớn bật tính năng này theo mặc định
    Phần giải thích cho độc giả phổ thông thì tốt, nhưng xét việc có nhiều client chặn được phần lớn rò rỉ dữ liệu bằng các quy tắc tường lửa như vậy và bài viết không ghi nhận các tiền lệ trong lĩnh vực này, tiêu đề có vẻ hơi phóng đại

    • Nhận xét đúng. Ngoại trừ những VPN thiếu cả quy tắc tường lửa cơ bản nên có khả năng đã rò rỉ rất nhiều rồi, đây không phải là lỗ hổng gì đáng kể
      Tôi suýt phun nước khi thấy cụm “tấn công kênh phụ”
      Sửa: xem ra NordVPN, ít nhất trên mac, không có quy tắc tường lửa mặc định như vậy nên có vẻ dễ bị tấn công này

  • Tôi không hiểu vì sao bài này lại dài đến vậy
    DHCP Option 121 cho phép máy chủ DHCP thiết lập quy tắc định tuyến cho một dải CIDR cụ thể; vì có tiền tố dài hơn nên nó có độ ưu tiên cao hơn quy tắc mặc định 0.0.0.0/0

    • Tôi là một trong các tác giả bài viết. Chúng tôi dự định giải thích các chủ đề liên quan trước vì nghĩ rằng sẽ có cả độc giả không có nền tảng kỹ thuật đọc bài
      Một nửa thông tin về VPN trên Internet là do các nhà cung cấp VPN viết, và chúng thường không chính xác hoặc không đủ kỹ thuật để giải thích VPN thực sự hoạt động ra sao
      Tôi đã định thêm ở phần mở đầu một câu dạng “nếu đã biết nội dung này thì hãy nhảy tới phần POC” kèm liên kết; tôi sẽ cập nhật để nó dễ thấy hơn
    • Và để kích hoạt cuộc tấn công này, kẻ tấn công phải ở cùng mạng lớp 2 với nạn nhân
      Tôi chưa đọc bài, chỉ đoán dựa trên bình luận phía trên

  • Tôi nhớ đã đọc về cuộc tấn công này từ một tác giả khác trước đây nên đã tìm lại, và sau khi vượt qua đống spam của các hãng VPN trong kết quả tìm kiếm, tôi tìm thấy công trình trước đó [1]
    Bài viết lần này đi sâu hơn vào cách khai thác lỗi và cũng có mã hữu ích cho proof of concept
    1: https://www.usenix.org/conference/usenixsecurity23/presentat...

    • Bài báo đó được tham chiếu trong phụ lục
      Tuy nhiên, cả hai kỹ thuật trong bài báo tháng 8/2023 đều không đẩy tuyến bằng DHCP option 121. Đẩy tuyến qua DHCP làm tăng tác động rất nhiều từ cùng một vị trí của kẻ tấn công. Ví dụ như vị trí có thể phát lease IP thuộc dải không phải RFC1918 hoặc giả mạo phản hồi DNS
    • “Cuộc tấn công” này đã được biết rộng rãi và cũng được dùng trong tùy chọn cấu hình redirect-gateway def1 của OpenVPN client

  • Mô hình đe dọa ở đây là một kẻ tấn công bất kỳ bằng cách nào đó có thể trở thành máy chủ DHCP trên LAN của tôi; khả năng thấp nhưng không phải bất khả thi
    Ngược lại, nếu bạn đang dùng thiết bị gateway do ISP cung cấp thì câu chuyện lại khác

    • Nếu ý là “một kẻ tấn công bất kỳ trở thành máy chủ DHCP trên LAN của tôi” là ít khả năng nhưng không phải bất khả thi, thì Wi-Fi quán cà phê chẳng phải chính là tình huống đó sao?
      Đó là điểm bán hàng số 1 của đa số sản phẩm VPN
      Trong trường hợp này, cách xử lý đúng là dùng kết nối 4G/5G và không kết nối vào những mạng đáng ngờ không tin cậy
    • Cách nói “máy chủ DHCP đó” ngầm giả định rằng trong mạng có một thiết bị đặc biệt riêng, nhưng giả định đó sai. DHCP là giao thức broadcast và thiết bị sẽ chấp nhận đề nghị đầu tiên
      Việc trong gia đình thông thường DHCP do router cung cấp và vì thế thường phản hồi đầu tiên chỉ là chi tiết phụ. Bất kỳ thiết bị độc hại nào trong mạng cũng có thể dùng lỗ hổng này
    • Một trong những ca sử dụng lớn của VPN chẳng phải là khi tôi không thể tin cậy mạng mình đang kết nối sao?
    • Hoặc trường hợp trở thành máy chủ DHCP trên Wi-Fi bên thứ ba mà tôi kết nối vào
    • Bảo vệ bạn trên các mạng Wi-Fi không tin cậy là một trong những lý do VPN thường quảng cáo

  • Trên Linux cũng có thể giảm thiểu bằng cách đưa giao diện VPN vào VRF. Ví dụ systemd-networkd hỗ trợ việc này mặc định
    Điểm cần chú ý là khi bật VRF, mục ip rule cho l3mdev được đặt là 1000, nhưng quy tắc lưu lượng local là 0. Cần chuyển quy tắc local lên 1000 trở lên

    • Ngày nay có cách nào chạy ứng dụng trong một VRF cụ thể không?

  • “Cuộc tấn công” này chỉ là một cách dùng khéo DHCP option 121. Nó là một cuộc tấn công hiệu quả với cấu hình client bị hỏng nặng
    Cách thay đổi tuyến mặc định, hoặc ghi đè bằng hai tuyến /1 rồi thêm tuyến host tới endpoint VPN, là không an toàn. Để cô lập đúng lưu lượng đã đóng gói khỏi mạng bên dưới, phải dùng định tuyến dựa trên chính sách. Ví dụ như Linux network namespace, FreeBSD vnet, OpenBSD rdomains
    Cách cố gượng ép ghép packet filter với “kill switch” ở user space vốn đã hỏng từ thiết kế, và cho thấy các nhà cung cấp hosting VPN phổ biến hiểu hoặc quan tâm ít đến mức nào về thứ lẽ ra là năng lực cốt lõi của họ. Lại là vấn đề cũ kiểu “liệt kê những thứ xấu”

  • Chuyện này chẳng có gì mới
    Tôi còn lo hơn cho những người bật IPv6 trên hệ thống nhưng lại dùng dịch vụ VPN chỉ hỗ trợ IPv4
    Điều đó thật sự có thể hỏng rất nặng

  • Có rất nhiều cách để vượt qua VPN trên thiết bị client. Vì vậy khi cần VPN, tôi thích đặt một router ở giữa client và Internet, nơi kết thúc đường hầm VPN và không có tuyến đường nào khác
    Những router du lịch như vậy rất dễ cấu hình để mang đi bất cứ đâu, và thực tế tôi đang làm như thế

    • Ở nhà, tôi rất khuyến nghị dùng router VPN chuyên dụng, trong đó mỗi router có mạng Wi‑Fi riêng. Tôi thấy cách này dễ kết nối và ổn định hơn so với việc chạy phần mềm VPN cục bộ trên từng thiết bị
      Ví dụ, có một router Wi‑Fi “work” luôn duy trì kết nối VPN tới intranet công ty, một Wi‑Fi “Australia” kết nối VPN tới máy chủ ở Úc mỗi khi muốn xem TV Úc, và cuối cùng là Wi‑Fi Internet gia đình thông thường
      Chỉ cần vài router Wi‑Fi cũ là làm được rất dễ, và có vẻ các router gia đình giá rẻ hiện nay cũng hỗ trợ VPN ở mức nào đó. Ngoài việc tập trung hóa cấu hình VPN để giảm khả năng mắc lỗi, lợi thế lớn là bất kỳ thiết bị nào chỉ cần kết nối vào Wi‑Fi đó là có thể dùng VPN
      Tôi đang dùng vài router cũ theo cách này, nhưng thật ra có lẽ cũng có thị trường cho một sản phẩm router gia đình duy nhất có thể thiết lập VPN tới nhiều vị trí trên thế giới và cung cấp các mạng Wi‑Fi khác nhau theo từng vị trí. Mục đích là để TV/Roku/iPad dễ dàng trông như đang truy cập từ một khu vực khác
    • Cuộc tấn công này chỉ khả thi khi có thiết bị không đáng tin cậy trong LAN cục bộ. Nếu bạn trực tiếp mang theo một gateway đã bật VPN, thì các thiết bị LAN không đáng tin cậy có lẽ không phải mối lo quá lớn
      Tuy nhiên, nếu trong LAN có thiết bị không đáng tin cậy và bạn dùng DHCP, thiết bị đó có thể dùng kỹ thuật này để nghe lén lưu lượng không được mã hóa*. Dù vậy, nó vẫn không tìm được IP thật vì gateway đã che giấu
      Nơi cuộc tấn công này thực tế nhất là các tình huống như Wi‑Fi quán cà phê. Ở những nơi như vậy, khả năng bạn mang router riêng theo là thấp
      Ở đây “lưu lượng không được mã hóa” nghĩa là lưu lượng không được đóng gói để gửi tới nhà cung cấp VPN. Ngày nay phần lớn là HTTPS nên bản thân nội dung của lưu lượng đó có lẽ vẫn được mã hóa
    • Nếu liệt kê vài phần cứng và phần mềm dùng được thì có lẽ sẽ đỡ mất công hơn
    • Có vẻ hầu hết router du lịch vẫn dễ bị ảnh hưởng bởi vấn đề này

  • Với người rành kỹ thuật thì nội dung này lẽ ra khá hiển nhiên, nhưng đây là phần giải thích nhập môn tốt về networking và VPN. Tôi đã cấu hình VM gateway VPN trên Linux vài lần, và kiến trúc chỉ dựa vào bảng định tuyến luôn khiến tôi thấy mong manh, đặc biệt khi nó chạy trên cùng một máy đang dùng kết nối đó
    Ngoài network namespace và router gateway VPN vật lý, kiến trúc dựa trên VM cũng có thể giải quyết vấn đề này. Trong homelab của tôi, firewall chặn lưu lượng ngoài dự kiến xuất phát từ VM gateway VPN. Các thiết bị trong VPN VLAN không thể kết nối trực tiếp ra ngoài, còn VM gateway có một VLAN riêng để kết nối ra bên ngoài
    Với giải pháp cá nhân, QubesOS cho phép thiết lập cấu hình tương tự với khá ít ma sát, nhưng dĩ nhiên vẫn đòi hỏi nhiều kiến thức kỹ thuật hơn hệ điều hành thông thường

  • Phần “Android là hệ duy nhất không bị ảnh hưởng vì chưa triển khai hỗ trợ DHCP option 121” khá thú vị
    Tôi tò mò liệu Google biết vấn đề này và cố ý đưa ra quyết định đó, hay hoàn toàn chỉ là tình cờ

    • Nhìn vào https://issuetracker.google.com/issues/117544989 thì có vẻ Google phần lớn đã phớt lờ yêu cầu tính năng này mà không đưa ra lý do. Tôi cũng thắc mắc điều tương tự. Có lẽ nhân viên Google có quyền truy cập Buganizer nội bộ sẽ biết thêm
      Nếu đoán thì nhóm networking của Android rất thân thiện với IPv6. Có vẻ họ không mấy quan tâm tới các tính năng ngách còn thiếu của IPv4. Ngay cả với IPv6, họ cũng có một tầm nhìn cụ thể về cách nên sử dụng nó, dẫn tới việc cố ý không hỗ trợ các tính năng như stateful DHCPv6
    • Có rất nhiều DHCP option, nên trong trường hợp như Android, chiến lược hợp lý là bắt đầu với mức hỗ trợ tối thiểu, rồi chỉ bật hỗ trợ bổ sung khi có nhu cầu đối với option nào đó
      DHCP option này không được dùng phổ biến, nên nếu theo chiến lược đó thì rất có thể nó đã không được hỗ trợ bất kể các lo ngại bảo mật
    • Android thậm chí còn chưa triển khai phiên bản DHCP mới đã được định nghĩa lần đầu từ 21 năm trước: https://www.rfc-editor.org/rfc/rfc3315
      Vì vậy cũng không quá ngạc nhiên