[Witarea] Re: draft-martin-retry-over-ipv6-02 requesting review/additional comments

[Lucas Pardue <[e-mail]>]

On Fri, Jul 3, 2026, at 19:53, Franck Martin wrote:
> This is not an open or fair question.

I disagree entirely. You proposal levies several requirements on clients. It should be cognisant of the operating environments those clients need to run in. By all means rephrase the question but the fundamental challenges for client implementers will stand. If client are not willing to change to address the IPv6 only desires, then an effort to standardise requirements on them is unlikely to succeed.

> 
> *From: *"Lucas Pardue" <[e-mail]>
> *To: *"Franck Martin" <[e-mail]>
> *Cc: *"witarea" <[e-mail]>
> *Sent: *Friday, July 3, 2026 11:47:05 AM
> *Subject: *Re: [Witarea] Re: draft-martin-retry-over-ipv6-02 requesting review/additional comments
> 
> Here's the type question you want to pose to the HTTP community:
> 
> "Some operators might want to limit the access to their services, for unexplained reasons, based solely on what they think a client IP might be. As a client implementation maintainer, would you be willing to add complexity and security/privacy/reliability risks to your codebase in order to support automatic actions in your discovery and connection selection logic?"
> 
> If the answer is no, then utilising existing HTTP extension points to signal information in responses so that they are surfaced to end users seem like a fine compromise for the foreseeable future. And it requires no IETF standards action.
> 
> On Fri, Jul 3, 2026, at 19:12, Franck Martin wrote:
>> The community on IPv6/IPv4 has always been divided. There are some for and some against deployment of IPv6, with some strong opinions. I'm trying to not be in any camp, except I'm thinking now of the future on how to best remove IPv4 as this is not easy and there is very little help.
>> 
>> Based on my past experience and the experience in the community (I have been deploying IPv6 for more than 20 years, while trying to retire IPv4, and in very large/huge deployments), some (law makers) have decided to terminate IPv4, as described in the introduction of the draft. They are few, but I believe the number will slowly rise. Now if they have decided to terminate IPv4, how the IETF can provide us, the maintainers of all those systems, with tools to do it as safely as possible to as you mention, minimize the impact on end users. There is also the case that technology like K8S is ghastly over IPv4, and IPv6-only deployments is more cost effective, if all the rest follows.
>> 
>> This is the purpose of this draft, it is not to mandate, but to propose: if you have to shut down IPv4, here is a way to reach that goal safely. At the moment, I don't know any safe way to do it, and I wish I had that tool to minimize the risk. I explain that part in the IPv6 migration in data centers draft. You can ensure your application works over IPv6-only, but it is very hard to do a reliable inventory of all the clients, and offer good roll backs, for the odd but very important client that represent less than 0.1% of the calls that you did not found in your analysis.
>> 
>> Side note, I found the talk on reddit to be very healthy with many weighting the pros and cons of various options. I think we can have the same here at the IETF, before shutting the door on this proposal outright.
>> 
>> Also, I thought the community is here too, so I'm doing just this, consulting the community with a proposal and the rational behind it. As you suggest, and as I hinted in the draft, we could look at other mechanisms in other protocols, and move the discussion to a higher level and make it into a BOF.
>> 
>> 
>> *From: *"Lucas Pardue" <[e-mail]>
>> *To: *"Franck Martin" <[e-mail]>
>> *Cc: *"witarea" <[e-mail]>
>> *Sent: *Thursday, July 2, 2026 6:07:05 PM
>> *Subject: *[Witarea] Re: draft-martin-retry-over-ipv6-02 requesting review/additional comments
>> 
>> The Internet is for end users [1]. Standardizing technology or process that actively encourages operators to deprive end users the ability to access services via the Internet does not seem like a positive outcome to me.
>> 
>> Operators can today, of their own volition, reject HTTP requests for any reason and return information in responses that can convey the reasoning. 
>> 
>> The proposal in the document would appear to pushing the burden on software and end users to take responsibility for reacting to a decision by an operator to reject an end user due to using a client IPv4 address seems out of proportion.
>> 
>> If you want to propose using HTTP to support driving arbitrary target set for a layer of the stack that is mostly irrelevant to HTTP, the discussion should start with consulting the HTTP community on the problem statement.
>> 
>> Cheers
>> Lucas
>> 
>> On Thu, Jul 2, 2026, at 23:42, Franck Martin wrote:
>>> I try to qualify as much as I can in the draft of why this is needed. Please read at least the draft introduction, and if it is not making the following points, I need to fix it.
>>> 
>>> 
>>> 
>>> The first point is that we may need something like this on the Internet in maybe 10 years from now.
>>> 
>>> The second more important point is that it is needed now within someone-controlled boundary. However, within this boundary, one never controls all the software present, and no company would maintain patched versions of gRPC, RESTLi, Curl, web browsers, observability software... it requires a common implementation guidance.
>>> 
>>> 
>>> Franck
>>> 
>>> 
>>> *From: *"Lucas Pardue" <[e-mail]>
>>> *To: *"witarea" <[e-mail]>
>>> *Sent: *Wednesday, July 1, 2026 3:19:00 PM
>>> *Subject: *[Witarea] Re: draft-martin-retry-over-ipv6-02 requesting review/additional comments
>>> 
>>> Wearing no hats.
>>> 
>>> Having skimmed the threads I don't think thst spending any standards effort on this is worthwhile. For example, a part of the linked spec states the proposal could be used in environments where the client and server have a shared administration. If so, they can do whatever they like.
>>> 
>>> A standard for this type of thing raises so many questions for actual common deployments of HTTP. Addressing them may be possible but I don't anticipate Internet deployment would end up caring to do anything.
>>> 
>>> 
>>> On Wed, Jul 1, 2026, at 21:27, Franck Martin wrote:
>>>> Hi Mirja,
>>>> 
>>>> 
>>>> 
>>>> Good suggestion.
>>>> 
>>>> 
>>>> 
>>>> Folks on httpbis,
>>>> 
>>>> 
>>>> 
>>>> This is about _draft-martin-retry-over-ipv6._ <https://datatracker.ietf.org/doc/draft-martin-retry-over-ipv6/>
>>>> 
>>>> 
>>>> 
>>>> It is about helping the retirement of IPv4 by providing some transition mechanisms. This is part of v6ops but it really needs some http expertise.
>>>> 
>>>> 
>>>> 
>>>> I'm not tied to a particular error code. I have tried to figure out which class would be best, between 4xx and 5xx. Some folks even suggested using 3xx, but I'm worried about infinite loops.
>>>> 
>>>> 
>>>> 
>>>> It may help to understand this draft by placing it into a bigger context, which is described in _draft-martin-deploying-ipv6-data-center._ <https://datatracker.ietf.org/doc/draft-martin-deploying-ipv6-data-center/>
>>>> 
>>>> 
>>>> 
>>>> There is also a short discussion on Reddit: _https://www.reddit.com/r/ipv6/s/lBQCFI4ucI_
>>>> 
>>>> 
>>>> 
>>>> and some past thread on v6ops/witarea
>>>> 
>>>> Franck Martin
>>>> https://www.peachymango.org/ 
>>>> 
>>>> 
>>>> *From: *"Mirja Kuehlewind" <[e-mail]>
>>>> *To: *"Franck Martin" <[e-mail]>, "v6ops" <[e-mail]>, "witarea" <[e-mail]>
>>>> *Sent: *Wednesday, July 1, 2026 1:51:41 AM
>>>> *Subject: *Re: [Witarea] draft-martin-retry-over-ipv6-02 requesting review/additional comments
>>>> Hi Franck,
>>>> you should probably also send this to the httpbis list.
>>>> Mirja
>>>> *From: *Franck Martin <[e-mail]> on behalf of Franck Martin <[e-mail]>
>>>> *Date: *Tuesday, 30. June 2026 at 20:49
>>>> *To: *v6ops <[e-mail]>, witarea <[e-mail]>
>>>> *Subject: *[Witarea] draft-martin-retry-over-ipv6-02 requesting review/additional comments 
>>>> Hi all, 
>>>> Some suggested that a 4xx code could be better, so I checked the pros and cons and added language in this draft on the various aspects of 566 vs 466. Also checked if there is any current behavior for common software for retrying after any HTTP error code.
>>>> Spolier alert: 566 still seems better.it is not an error on the client part, It is the server that refuses to honor the connection.
>>>> This new draft has this added language: 
>>>> https://datatracker.ietf.org/doc/draft-martin-retry-over-ipv6/ 
>>>> To be noted, I implemented this draft on my site: https://pacific.ipv6forum.com/ so that on the 6th of every month, IPv4 is not served. I had some implementation nits that prevented me from getting good logs. I hope this time I will have better logs, therefore better reports to share with folks.
>>>> In a couple of days, the site will show a banner announcing the IPv4 outage.
>>>> At the moment, I have not convinced a WG to formally “host” the discussion. I won’t be able to attend IETF Vienna as to gather more support, but appreciate if some folks could be a proxy.
>>>> Franck Martin
>>>> https://www.peachymango.org 
>>>> -- 
>>>> Witarea mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>> 
>>> 
>>> 
>>> --
>>> Witarea mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>> 
>> 
>> --
>> Witarea mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]