[123attendees] Re: Issues with IPv4 address instability - only for people from Netherlands?

[Erik Nygren <[e-mail]>]

This is certainly a recurring issue and has also been one of the major
blockers for some content providers to dual-stack.  There are apparently
some media content owners who include contract requirements to lock tokens
or other authenticators to IP addresses.

I worked with our product folks a few years ago to write a blog post on
this that we can point people at (eg, to allow our customers, but also
others, to explain to content owners why this is an anti-pattern):
https://www.akamai.com/blog/developers/why-you-shouldn-t-tie-ip-addresses-to-tokens

It would be worthwhile to have an IETF draft/RFC that calls this out as a
practice to avoid (Worst Common Practice?) so that there's a
vendor-agnostic reference.

   Erik


On Thu, Jul 24, 2025 at 3:21 PM Ondřej Caletka <[e-mail]>
wrote:

> Jordi,
>
> On 24/07/2025 14:43, [e-mail] wrote:
>
> This problem also happens in some applications when using dual-stack, and
> the connection for whatever reason falls-back from IPv6 to IPv4 (because
> HE) and viceversa, recovers from IPv4 to IPv6.
>
> Indeed, everybody who deployed dual-stack knows very well that you cannot
> expect that single user behind single browser will always be represented by
> a single IP address. However, those that still haven't deployed IPv6 still
> think that checking that the user is consistently coming from the same IP
> address is a good thing to do for a better security. And it arguably
> prevents some attacks like session cookie stealing.
>
> The point here is should apps relay on IP address?
>
> They should not, but many people still consider this a security feature.
>
> The thing is, all the ISPs that have deployed CGN apparently know that it
> is necessary to enable "address stickyness" in order to prevent a number of
> support calls. Yet people who are new to this NAT business have to learn
> this the hard way. And since the vast majority of the CGNs out there are
> set up in this sticky-way, if your network does not work with that
> particular website while other networks do, you still need to fix it in
> your network even if the issue is on the website end.
>
> --
> Ondřej
>
>
> Regards,
> Jordi
>
> @jordipalet
>
>
> El 23 jul 2025, a las 19:26, Ondřej Caletka <[e-mail]>
> <[e-mail]> escribió:
>
> Hey,
>
> I reported yesterday that the default network called ietf has issues
> with some IPv4-only websites due to the fact that the current setup of
> NAT64 maps each individual session to possibly different IPv4
> addresses. You can see it by opening your favourite "What is my IPv4"
> website and refreshing the browser a few times.
>
> This does not present a problem for most services, but there are some
> websites whose authors didn't expect that a single user behind a
> single browser can be accessing the web server from several IPv4
> addresses. Typical cases are DRM protected video-on-demand websites
> where the browser first asks for a license and this license/token is
> then valid only for the IPv4 address from which it was requested.
>
> An example of such a website is https://nos.nl/l/2576078 but I also
> noticed that HR software called AFAS Insite gets completely broken in
> such a situation.
> Since I have a theory that users tend to suffer in silence, I would
> like to gauge if I am really the only one noticing this or if there is
> anyone else who spotted something not working as usual but considered
> it too minor to report. Please report broken websites (possibly also
> to the owners of those websites.)
>
> --
> Best regards,
> Ondřej Caletka
>
> _______________________________________________
> 123attendees mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
> _______________________________________________
> 123attendees mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> 123attendees mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>