[v6ops] Re: IPv6-mostly deployment at RubyKaigi

[Sorah Fukumori <[e-mail]>]

Hi Jen,

We completed the re-verification of our investigation, and invalidated the
explanation regarding a source address in solicited NAs. I've updated our
blog post accordingly. Thanks again for the information.

-

Regarding draft-ietf-v6ops-6mops-04:

I appreciate the opportunity to review this I-D. I'm not a frequent
participant in the standardization process though, but I'd like to leave
comments as follows:

1. Section 7.4. Paragraph 2.1.1.

   > If NAT44 is employed, then NAT64 and NAT44 must share the same pool of
IPv4 addresses.

   Is this going to be marked as MUST?

   Our deployment used a separate NAT device for NAT64 flow to isolate with
the existing setup, to allow safe and easy fallback to our battle-tested
NAT44 infrastructure; also because our existing NAT44 devices don't support
NAT64.  Therefore we had separate NAT IPv4 address pools; We offer
stickiness, but it is scoped and bound to each pool. We considered this
limitation negligible, because our network is temporary where it only lasts
3-days.

   Plus, a rotation of random IPv6 addresses also could invalidate NAT
address stickiness; in mid-term, randomised MAC addresses could also
change; IIRC Apple devices rotate every 2 weeks by default, which
effectively prevents from tracking required for stickiness.

   I agree that switching between dualstack and IPv6-only mid-connection
can cause such problems if a NAT pool isn't shared, I don't think it's
worth enough that requiring sharing NAT pools as MUST, while I agree it is
valuable mentioning to network operators who are going to migrate their
networks incrementarily.

2. Section 7.5.3. Paragraph 7.

   > However, the deployment model described in [RFC9663] might not yet be
supported by all endpoints

   This might be "by all devices?" AFAIK wireless controllers still track
IPv6 addresses of clients via its presence in packets or DHCP snooping. RFC
9663 must be recognised in all intermediate boxes such as WLCs in order to
eliminate such scalability issues.

Best,
Sorah


On Wed, 5 Nov 2025 at 06:16, Sorah Fukumori <[e-mail]> wrote:

> Hi Jen, thank you for the response.
>
> On Tue, 4 Nov 2025 at 23:49, Jen Linkova <[e-mail]> wrote:
> > 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.
>
> On Wed, 5 Nov 2025 at 02:28, Jen Linkova <[e-mail]> wrote:
> > 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.
>
> Oh - I started to double check my investigation log, and the source
> address thingy in my report might be inaccurate - I'll update the blog
> post and this email thread later.
>
> # Perhaps one of our packet captures was mistakenly recognised as a
> wired connection, and our controller converted or generated solicited
> NAs that sent using GUA (non-lladdr).
> # And I regret that I didn't include 15.4 on the onsite test :/
>
> Meanwhile please disregard the source address thingy in my report,
> sorry for making confusion.
>
> > 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!).
>
> Appreciated on the info that the change made in macOS 15.5.
> # And I regret that I didn't include 15.4 on the follow-up test. I
> misrecognised 15.5 was released before the first conference, so it was
> out of scope due to the time limit on follow-up test; that was
> performed on the conference setup day
>
> > Have you reported it to Cisco?
>
> Not yet, but honestly we currently don't have active support contract
> with them (as we're a community, voluntary based conference)
>
> > > 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?
>
> Thanks, we'll check later.
> --
> Sorah Fukumori https://sorah.jp/
>


-- 
Sorah Fukumori https://sorah.jp/