[v6ops] Re: IPv6-mostly deployment at RubyKaigi

[Jen Linkova <[e-mail]>]

Hi Sorah.

On Tue, Nov 4, 2025 at 2:23 PM Sorah Fukumori
<her=[e-mail]> wrote:
> We have deployed IPv6-mostly conference Wi-Fi at two conferences that we organized this year.
>
> We'd like to share our blog post covering our experience with deploying RFC 8925 and issues we discovered with Apple devices that had an interoperability issue when combined with Cisco WLC 3504. It appears to have been fixed in the newly released macOS 26 and iOS 26, but we hope this will be helpful for others deploying IPv6-mostly networks as many Apple devices on earlier versions remain in use.
>
> Blog post: https://blog.sorah.jp/2025/11/04/mystery-of-clat-on-apple-devices
>
> tl;dr:
>
> 1. On our first IPv6-mostly Wi-Fi, Apple devices (macOS 15 Sequoia, iOS 18) could lose IPv4 connectivity after ~30 minutes
>
> 2. We discovered that Apple devices don't respond correctly to unicast Neighbor Solicitations for CLAT addresses; the source addresses in solicited NAs are set to link-local addresses instead. We suspect this causes CLAT address entries to expire from WLC's Neighbor Binding table
>    - However, I am uncertain whether this source address behavior is compliant with RFC 4861 and related RFCs. At least our Cisco WLC 3504 did not appear to process such packets.

I do not see anything in RFC4861 which would prohibit such behavior.
https://www.rfc-editor.org/rfc/rfc4861.html#section-4.4 says that the
Source Address in NA is "An address assigned to the interface from
which the advertisement is sent.". I can only read it as any interface
address is allowed and, to be honest, I'd say using the link-local
address makes sense.

https://www.rfc-editor.org/rfc/rfc4861.html#section-7.2.5 doesn't
require the source address to be the target address either.

So, to be honest, it looks more like a bug in the WLC code.


>    - (AFAIK a related discussion can be found on draft-ietf-v6ops-claton-10)

Oh that discussion is related to yet *another* bug in MacOS which was
fixed earlier: until 15.5, MacOS didn't respond to the unicast NSes
for the CLAT address at all.
It was reported and very promptly fixed (thank you, Apple people!).

> 3. We also verified that a fix was delivered in the latest macOS/iOS releases (macOS 26 Tahoe and iOS 26). Solicited NAs now use the correct source addresses.
>    - For earlier Apple OS versions, the issue was mitigated by increasing binding lifetime in WLC.

Have you reported it to Cisco?

> 4. By enabling RFC 8925, approx 80% of IPv4 traffic automatically went to NAT64 boxes. This is wonderful, kudos to RFC authors and implementers!

Wow, cool, thank you for sharing your experience!

May I ask you to review
https://datatracker.ietf.org/doc/draft-ietf-v6ops-6mops/ to see if
there is anything you'd like to add/share?

-- 
Cheers, Jen Linkova