Re: [v6ops] About Req for Comments - "Transition to IPv6"

Owen DeLong <owen@delong.com> Fri, 13 March 2020 22:16 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F3F3A1127 for <v6ops@ietfa.amsl.com>; Fri, 13 Mar 2020 15:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.098
X-Spam-Level:
X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hY0vpIqjGU_E for <v6ops@ietfa.amsl.com>; Fri, 13 Mar 2020 15:16:46 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 69ED23A1128 for <v6ops@ietf.org>; Fri, 13 Mar 2020 15:16:46 -0700 (PDT)
Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 02DMGgDP2850594 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Mar 2020 15:16:42 -0700
From: Owen DeLong <owen@delong.com>
Message-Id: <28EEE40B-D558-45FD-9C30-5AB7593A29B2@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9BBDD850-85FF-40C4-B9F7-21FF2E5E061B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 13 Mar 2020 15:16:41 -0700
In-Reply-To: <3854B1F6-0DB8-4753-BBDD-30AAD391C4DC@consulintel.es>
Cc: v6ops <v6ops@ietf.org>
To: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
References: <e8a25961-5ac9-d35e-77dd-bf86f45cd077@gmail.com> <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <ccc75efb-8c00-ee97-5cc7-2e061e6e5a54@gmail.com> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <D2622B27-88F4-42A7-B944-C002F40D0DB7@consulintel.es> <2020030818294834486735@chinatelecom.cn> <CADzU5g5yzhK-4oxL=m5_C1fj=K7nXX9mDG49=gLRSs8XGkPXqA@mail.gmail.com> <B8678AA0-7D7A-4ACD-BB4A-DDEDE85ACB88@consulintel.es> <073925C4-5355-4C51-84A4-4D9545013552@delong.com> <4A5BDEE6-2B9E-4338-94C1-3BE9D6E37516@consulintel.es> <CFFE746A-35C6-4236-9ECC-EF1E6222BFD7@delong.com> <3854B1F6-0DB8-4753-BBDD-30AAD391C4DC@consulintel.es>
X-Mailer: Apple Mail (2.3445.104.11)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 13 Mar 2020 15:16:42 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/k2McqG1uOjuLcqWCkhK8nS2A-sc>
Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2020 22:16:48 -0000


> On Mar 12, 2020, at 02:22 , JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> wrote:
> 
> Hi Owen,
> 
> Using +++ below …
> 
I have to again restate that it would be vastly preferable if you got an MUA that actually worked.

>  
>  
> El 10/3/20 21:49, "v6ops en nombre de Owen DeLong" <v6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org> en nombre de owen@delong.com <mailto:owen@delong.com>> escribió:
>  
>  
> 
> 
>> On Mar 10, 2020, at 11:25 , JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org <mailto:jordi.palet=40consulintel.es@dmarc.ietf.org>> wrote:
>>  
>> Hi Owen,
>>  
>> Responses below with ***.
>>  
>> El 10/3/20 19:03, "v6ops en nombre de Owen DeLong" <v6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org> en nombre de owen@delong.com <mailto:owen@delong.com>> escribió:
>>  
>>  
>> 
>> 
>> 
>>> On Mar 9, 2020, at 01:42 , JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org <mailto:jordi.palet=40consulintel.es@dmarc.ietf.org>> wrote:
>>>  
>>> Hi Clark,
>>>  
>>> El 8/3/20 12:38, "v6ops en nombre de Clark Gaylord" <v6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org> en nombre de cgaylord@vt.edu <mailto:cgaylord@vt.edu>> escribió:
>>>  
>>> It seems to me the context of the OMB guidance is relevant to the question of "IPv6-only". The draft memo is reasonably good at this, but succinctly something like "agency internal networks use single-stack IPv6 with any 
>>>  
>>> [Jordi] I don’t think is so clear. Footnote 4 “IPv6-Only refers to network environments in which use of the IPv4 protocol has been eliminated” will be much clear if it says “IPv6-Only refers to network environments in which use of the *native* IPv4 protocol has been eliminated”.
>>  
>> I don’t believe that what you propose is the intent in the memo.
>>  
>> I believe they intend to eliminate the use of ALL IPv4, not just native IPv4 on government networks.
>>  
>> *** Then there is a problem. If they really want to have ALL the way thru only IPv6 in the LANs, the federal employees will not be able to use *ANY* application that uses literal addresses (even a simple web page that is doing that). Because there is NO transition mechanism that allows that. They are able to force all their internal apps to use only IPv6, fine, but they have no control over the rest of the Internet. If they are thinking that NAT64+DNS64 resolves that, they lost this “small” bit in their thinking. I’ve already reported them to the site that is asking for comments, hopefully they really pay attention to the inputs.
>  
> I don’t see that as a problem… I see that as a benefit.
>  
> I think that the US Federal government is one of the few organizations in a position to actually put the kind of pressure that will be necessary to effectuate this change.
>  
> So, personally, I don’t see it so much as “they lost this in their thinking” as in they are choosing to stop supporting certain “broken by design” ways of thinking.
>  
> I hope that they stick to their guns and do not soften their position.
>  
> +++ Somehow, I agree, is not a “problem”, depending on how you see it. As moving on to a real IPv6-only world, it is good. But we are interpreting the document as they really want that. They don’t say explicitly, so we don’t know. If they want that effect, I think it will be much better message to say “we know this will create this problem for people still using literal IPv4 addresses in web sites, but they should react if they want to work with us” or whatever..

I know many of the people involved. I suspect that the authors of the document do, in fact, intend that.

What you propose would be the customer friendly way for a business to approach it. It isn’t culturally typical of the US Government to approach anything in a customer friendly manner.

>>  
>> *** I will be glad if they can send this memo to every small web site in the world, because even if one of them is missing it, and need to be accessed by the employees, will not work!
>  
> I’m pretty sure that the employees that encounter difficulty will make it known to the web sites in question.
>  
> +++ Not sure, it may get ignored, as they ignore problems in their deployment. Last time I tried to fill in the ESTA for traveling to US, it was not working in some of the final steps. I did some debugging and realized that they were dual stack, but filtering PTB, so because the MTU at some point in the network, it never worked until I disabled IPv6 to complete the form and pay the fee. I tried to tell them. I recall there was even a thread about that in NANOG (talking from the top of my head, it may be in a different list). They never responded or resolved it. I’m not sure if now the problem is still there.

We’re talking about two different things here…

In your case, you were  trying to get the government to fix something they broke. The government is very good at ignoring such feedback.

In this case, we’re talking about government employees informing web sites they are trying to visit that they are no longer accessible from US Government networks. That’s not something web sites are nearly as likely to ignore.
 
> In reality, in terms of actual job-related usage, the federal government is unlikely to need access to every small web site in the world. As a general rule, every small web site in the world has no ability to support things at the scale of US Government usage.
>  
> +++ Sometimes this happens even in bigger sites … so yes and not.

I’m quite certain the bigger sites will get the memo somehow. If they don’t get it before this starts taking hold of their USG customers, they will certainly learn about it and quickly mitigate it afterwards. ;-)

> +++  Fully agree! But some text could make it more clear, so nobody believes “they didn’t though about this issue” as I did.

I’m not sure how much experience you have with the USG, but if you think clarity is their strong suit, I suggest you read 14CFR121 and get back to me.

Owen