Return-Path: X-Original-To: witarea@mail2.ietf.org Delivered-To: witarea@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 3A9BD10DFEC8E for ; Fri, 3 Jul 2026 12:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783106944; bh=AjD7XwCVEmTxoI+y0Wx/Wdo1LBj6tmqI7IBXhpKK57k=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=bUiN3+bQ3zMpPxUCopvyNPrSl5+wUz81QS4WWhL880uTqdC3DyM32Uy0ZtfcKw00V QcIWaZipm9b101BA3gXvBceX4iGIDDbxNhsfOmjjj8vUBNzFirxEdKhuTy5bUc9DOR r3rF6Qf3q+tTfK7LNG9bCNBAXWixKd4bafGMkq9o= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=lucaspardue.com header.b="bMqBn/Bh"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="lXUJOSZx" Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr20vgfRiQZ7 for ; Fri, 3 Jul 2026 12:29:02 -0700 (PDT) Received: from fhigh-b2-smtp.messagingengine.com (fhigh-b2-smtp.messagingengine.com [202.12.124.153]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id EAE9010DFEBD5 for ; Fri, 3 Jul 2026 12:29:00 -0700 (PDT) Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id 936277A0049; Fri, 3 Jul 2026 15:29:00 -0400 (EDT) Received: from phl-imap-03 ([10.202.2.93]) by phl-compute-02.internal (MEProxy); Fri, 03 Jul 2026 15:29:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucaspardue.com; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1783106940; x= 1783193340; bh=AjD7XwCVEmTxoI+y0Wx/Wdo1LBj6tmqI7IBXhpKK57k=; b=b MqBn/BhDzmXlfV2mn86cy9q6EUCCaY55/mGmseOWNZdod87XB/EhCNMWVB0BFgjK a9cu76mEd/2KT0MlxV2wWd0k29BMIZHn1VhnHGRzjSMPKxNscyJab7Tf5jvTjpyP hQugKwnZhgzGGZm3vvOrWgJWPdZ/ZI6VfiubbtD3wHAO+uwxhsBfTAHKbBvvBUDJ BS7xFXgkC8ssmeUBtTnoasF+YuPYObYsrlzEvoreT+mEiQ1b7QCBvODTQv8TYM+d 5K9EpEFIgK6xHsV9UtS/CT16L8oSGF6kR5vo8yIgomvOWkuueE2UkXlqeRhrFr8E 7vzK3bJQkL7LHMZhW99IQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1783106940; x=1783193340; bh=AjD7XwCVEmTxoI+y0Wx/Wdo1LBj6tmqI7IB XhpKK57k=; b=lXUJOSZxmEvJc1vfBbkMc65WyTMLEbTBSU1VTb1eofe/NENe9Jp 1qPJnr0Ndiej0iQeTFLcQSQYK/9aaTPQ6gw/JXaVIgbNEHPQY7/mMn/2Y4cTL0Vd pAgZU3lmseJGspq9ytbWRVF8vwFnV1rWXhbqujo0vlFKjVVX4IE2I5iyG9FrqagI 3g5sv8txcD+99MrOkvGkfT5/JG2gpACj+bTA5wU2PAxMrosUYePI0sMGSzhzG10C zh2Lk7BI0tlBgdEwVrP85yHZ6j90XOcbwuuUrJNs+cpmnO4+ypuJTbcH9c7nVRMS io4CXoQQd1nJ6XQtyZ+l0K0epQjBKRRpRmA== X-ME-Sender: X-ME-Proxy-Cause: dmFkZTFZkJgZyWJsnO7nCPkeMjWKvDF4RjcG2VC4VH1Xz0dL0og4mkZj7Zs7bLaZkac2za zQ8C5lhP5Xaapqt4gGlYqkYAAgkmOr4cy1XzS8p+CuxGt12Tf9wWrJc4OaiUeyw3DuFg12 rSE88pzGiyHC30iR8zglrKGG4b7jpyOAIV+FcsZ+L8kOHzPYO5U23xsRQEIK5KWr5GxrNi pYWpqHg0LiJJ/+cnPs8NzNVSYzKarrK92c+rALReyYyVhEZXmV8bskJ3iSKv5J+zWazDVf Uh/ICQyPO2Edqo1aRp6CZD92Rb9Umc2DFW+pTyGq+2p28p+5Lrj+8IIaL0N9rSx0XlAegV kTlckAN3awNxwP51ffOOmaXxKzQF8k+ah67YsIc1mQiLwyGez5K5pyx+b15j1cCVrfOlT1 YhQRcvjqxb1OWixCvB7/BAfw0d/cJ7Oy0R+S2nfieLGd2PxKqX4j8rrx3TmE3HXaeus4gJ skVQ+vW8tfsIk5Gs9Zq2N87+LJUXJIdi3k7L4aSIW9mUCLZW28HMS3+ZiM/aZJDijvqlTZ XzdbDkwHZEnGs/dvJjFvtEP6JAuWluoF/iqcBqAg33VqcDFFJ4PerdzVcb2ZJsgUnh7fdv mwE/bxRjutk3VDAu7J040Ym6kyGuHKgx8fW9w9z+YVDvzn94VxnaoMam7B3g X-ME-Proxy: Feedback-ID: i23b94938:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id D0C1018E006C; Fri, 3 Jul 2026 15:28:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: AYq4uGD7aKWs Date: Fri, 03 Jul 2026 20:27:52 +0100 From: "Lucas Pardue" To: "Franck Martin" Message-Id: <4940ab6e-cc24-40b5-85ec-3b6ff0bfa492@app.fastmail.com> In-Reply-To: <1028203045.53547521.1783104817162.JavaMail.zimbra@peachymango.org> References: <1789666940.33457565.1782937621585.JavaMail.zimbra@peachymango.org> <7228df10-1dc3-4a2b-addc-d2aa93c60cdd@app.fastmail.com> <1182691430.45301794.1783032151849.JavaMail.zimbra@peachymango.org> <1137890800.53231581.1783102348406.JavaMail.zimbra@peachymango.org> <1028203045.53547521.1783104817162.JavaMail.zimbra@peachymango.org> Content-Type: multipart/alternative; boundary=b522ce7233c05972c3cd622ab356facc132c126d Message-ID-Hash: MYPELZB3CRWXTNMZBXLMGCHBANNVGBYA X-Message-ID-Hash: MYPELZB3CRWXTNMZBXLMGCHBANNVGBYA X-MailFrom: lucas@lucaspardue.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: witarea X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BWitarea=5D_Re=3A_draft-martin-retry-over-ipv6-02_requesting_rev?= =?utf-8?q?iew/additional_comments?= List-Id: "Web and Internet Transport (WIT) Area" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --b522ce7233c05972c3cd622ab356facc132c126d Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 nee= d to run in. By all means rephrase the question but the fundamental chal= lenges for client implementers will stand. If client are not willing to = change to address the IPv6 only desires, then an effort to standardise r= equirements on them is unlikely to succeed. >=20 > *From: *"Lucas Pardue" > *To: *"Franck Martin" > *Cc: *"witarea" > *Sent: *Friday, July 3, 2026 11:47:05 AM > *Subject: *Re: [Witarea] Re: draft-martin-retry-over-ipv6-02 requestin= g review/additional comments >=20 > Here's the type question you want to pose to the HTTP community: >=20 > "Some operators might want to limit the access to their services, for = unexplained reasons, based solely on what they think a client IP might b= e. As a client implementation maintainer, would you be willing to add co= mplexity and security/privacy/reliability risks to your codebase in orde= r to support automatic actions in your discovery and connection selectio= n logic?" >=20 > If the answer is no, then utilising existing HTTP extension points to = signal information in responses so that they are surfaced to end users s= eem like a fine compromise for the foreseeable future. And it requires n= o IETF standards action. >=20 > On Fri, Jul 3, 2026, at 19:12, Franck Martin wrote: >> The community on IPv6/IPv4 has always been divided. There are some fo= r and some against deployment of IPv6, with some strong opinions. I'm tr= ying 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. >>=20 >> Based on my past experience and the experience in the community (I ha= ve been deploying IPv6 for more than 20 years, while trying to retire IP= v4, and in very large/huge deployments), some (law makers) have decided = to terminate IPv4, as described in the introduction of the draft. They a= re few, but I believe the number will slowly rise. Now if they have deci= ded to terminate IPv4, how the IETF can provide us, the maintainers of a= ll those systems, with tools to do it as safely as possible to as you me= ntion, minimize the impact on end users. There is also the case that tec= hnology like K8S is ghastly over IPv4, and IPv6-only deployments is more= cost effective, if all the rest follows. >>=20 >> This is the purpose of this draft, it is not to mandate, but to propo= se: if you have to shut down IPv4, here is a way to reach that goal safe= ly. 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 migratio= n 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 ana= lysis. >>=20 >> Side note, I found the talk on reddit to be very healthy with many we= ighting the pros and cons of various options. I think we can have the sa= me here at the IETF, before shutting the door on this proposal outright. >>=20 >> Also, I thought the community is here too, so I'm doing just this, co= nsulting the community with a proposal and the rational behind it. As yo= u suggest, and as I hinted in the draft, we could look at other mechanis= ms in other protocols, and move the discussion to a higher level and mak= e it into a BOF. >>=20 >>=20 >> *From: *"Lucas Pardue" >> *To: *"Franck Martin" >> *Cc: *"witarea" >> *Sent: *Thursday, July 2, 2026 6:07:05 PM >> *Subject: *[Witarea] Re: draft-martin-retry-over-ipv6-02 requesting r= eview/additional comments >>=20 >> The Internet is for end users [1]. Standardizing technology or proces= s 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. >>=20 >> Operators can today, of their own volition, reject HTTP requests for = any reason and return information in responses that can convey the reaso= ning.=20 >>=20 >> The proposal in the document would appear to pushing the burden on so= ftware and end users to take responsibility for reacting to a decision b= y an operator to reject an end user due to using a client IPv4 address s= eems out of proportion. >>=20 >> 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 dis= cussion should start with consulting the HTTP community on the problem s= tatement. >>=20 >> Cheers >> Lucas >>=20 >> 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 t= he following points, I need to fix it. >>>=20 >>>=20 >>>=20 >>> The first point is that we may need something like this on the Inter= net in maybe 10 years from now. >>>=20 >>> The second more important point is that it is needed now within some= one-controlled boundary. However, within this boundary, one never contro= ls all the software present, and no company would maintain patched versi= ons of gRPC, RESTLi, Curl, web browsers, observability software... it re= quires a common implementation guidance. >>>=20 >>>=20 >>> Franck >>>=20 >>>=20 >>> *From: *"Lucas Pardue" >>> *To: *"witarea" >>> *Sent: *Wednesday, July 1, 2026 3:19:00 PM >>> *Subject: *[Witarea] Re: draft-martin-retry-over-ipv6-02 requesting = review/additional comments >>>=20 >>> Wearing no hats. >>>=20 >>> 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 st= ates the proposal could be used in environments where the client and ser= ver have a shared administration. If so, they can do whatever they like. >>>=20 >>> A standard for this type of thing raises so many questions for actua= l common deployments of HTTP. Addressing them may be possible but I don'= t anticipate Internet deployment would end up caring to do anything. >>>=20 >>>=20 >>> On Wed, Jul 1, 2026, at 21:27, Franck Martin wrote: >>>> Hi Mirja, >>>>=20 >>>>=20 >>>>=20 >>>> Good suggestion. >>>>=20 >>>>=20 >>>>=20 >>>> Folks on httpbis, >>>>=20 >>>>=20 >>>>=20 >>>> This is about _draft-martin-retry-over-ipv6._ >>>>=20 >>>>=20 >>>>=20 >>>> It is about helping the retirement of IPv4 by providing some transi= tion mechanisms. This is part of v6ops but it really needs some http exp= ertise. >>>>=20 >>>>=20 >>>>=20 >>>> 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 suggest= ed using 3xx, but I'm worried about infinite loops. >>>>=20 >>>>=20 >>>>=20 >>>> It may help to understand this draft by placing it into a bigger co= ntext, which is described in _draft-martin-deploying-ipv6-data-center._ = >>>>=20 >>>>=20 >>>>=20 >>>> There is also a short discussion on Reddit: _https://www.reddit.com= /r/ipv6/s/lBQCFI4ucI_ >>>>=20 >>>>=20 >>>>=20 >>>> and some past thread on v6ops/witarea >>>>=20 >>>> Franck Martin >>>> https://www.peachymango.org/=20 >>>>=20 >>>>=20 >>>> *From: *"Mirja Kuehlewind" >>>> *To: *"Franck Martin" , "v6ops" , "witarea" >>>> *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 on behalf of Franck = Martin >>>> *Date: *Tuesday, 30. June 2026 at 20:49 >>>> *To: *v6ops , witarea >>>> *Subject: *[Witarea] draft-martin-retry-over-ipv6-02 requesting rev= iew/additional comments=20 >>>> Hi all,=20 >>>> Some suggested that a 4xx code could be better, so I checked the pr= os and cons and added language in this draft on the various aspects of 5= 66 vs 466. Also checked if there is any current behavior for common soft= ware for retrying after any HTTP error code. >>>> Spolier alert: 566 still seems better.it is not an error on the cli= ent part, It is the server that refuses to honor the connection. >>>> This new draft has this added language:=20 >>>> https://datatracker.ietf.org/doc/draft-martin-retry-over-ipv6/=20 >>>> To be noted, I implemented this draft on my site: https://pacific.i= pv6forum.com/ so that on the 6th of every month, IPv4 is not served. I h= ad some implementation nits that prevented me from getting good logs. I = hope this time I will have better logs, therefore better reports to shar= e with folks. >>>> In a couple of days, the site will show a banner announcing the IPv= 4 outage. >>>> At the moment, I have not convinced a WG to formally =E2=80=9Chost=E2= =80=9D the discussion. I won=E2=80=99t 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=20 >>>> --=20 >>>> Witarea mailing list -- witarea@ietf.org >>>> To unsubscribe send an email to witarea-leave@ietf.org >>>>=20 >>>=20 >>>=20 >>> -- >>> Witarea mailing list -- witarea@ietf.org >>> To unsubscribe send an email to witarea-leave@ietf.org >>=20 >>=20 >> -- >> Witarea mailing list -- witarea@ietf.org >> To unsubscribe send an email to witarea-leave@ietf.org --b522ce7233c05972c3cd622ab356facc132c126d Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable