[v6ops] Re: IPv6-mostly deployment at RubyKaigi

[Jen Linkova <[e-mail]>]

Hi Sorah,

Thank you for your review!

On Mon, Nov 10, 2025 at 3:57 AM Sorah Fukumori <[e-mail]> wrote:
> 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.

Ah good point - I believe Med also commented on that. I agree that the
normative language is unnecessary here, the text will be updated in
the next revision.

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

The key word in the doc is "concurrent". The goal here is to ensure
that when a host opens multiple sessions to an external IPv4-only
system, all those sessions use the same source IPv4 address.
It is not the same as using the same IPv4 pool address to a given host
every day.

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

Yes, good point, the text will be rephrased.

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

Yes, the network infrastructure needs to support PD per device too.
I'll update the text.

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



-- 
Cheers, Jen Linkova