[v6ops] Re: IPv6-mostly deployment at RubyKaigi

[Jen Linkova <[e-mail]>]

On Wed, Nov 5, 2025 at 1:49 AM Jen Linkova <[e-mail]> wrote:
> > 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.

Another datapoint: my Macbook which still sends NAs for the CLAT
address from the link-local source, has no issues staying on various
IPv6-mostly networks (incl. my corporate network, RIPE conference
network and the IETF network.
So it does look like your controller might make unnecessary strict
assumptions, seems to be worth reporting to the vendor.

> >    - (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



-- 
Cheers, Jen Linkova