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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 12 March 2020 09:23 UTC

Return-Path: <prvs=1340af7d02=jordi.palet@consulintel.es>
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 2216A3A00C1 for <v6ops@ietfa.amsl.com>; Thu, 12 Mar 2020 02:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.999, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 pWB3b-HktRWk for <v6ops@ietfa.amsl.com>; Thu, 12 Mar 2020 02:23:04 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E323A0042 for <v6ops@ietf.org>; Thu, 12 Mar 2020 02:23:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1584004981; x=1584609781; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=EoKc1Q2uwhrQGqMgkLJOZQdjxPKLqY4kKQ mbkghCHqs=; b=wmwF3fsqd4KMJ5SVczWhz5qfj0Wn0vwoLVduLworqSFBkpsQhI dOopZICBtM+hHzdyqMZRwlXIGu9mfBQBlPC6D1AaWqaQ/zZCdmx83VokJmDe+mPS hqE24ROue8AFXIuRY6ALI0UwjuSX1HJgFd5xww3Hv7i840s2L7+F8TSCM=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 12 Mar 2020 10:23:01 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 12 Mar 2020 10:22:59 +0100
Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000088903.msg for <v6ops@ietf.org>; Thu, 12 Mar 2020 10:22:58 +0100
X-MDRemoteIP: 2001:470:1f09:495:e0a6:81ab:ea8d:1a06
X-MDHelo: [10.10.10.144]
X-MDArrival-Date: Thu, 12 Mar 2020 10:22:58 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1340af7d02=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/16.35.20030802
Date: Thu, 12 Mar 2020 10:22:55 +0100
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: v6ops <v6ops@ietf.org>
Message-ID: <3854B1F6-0DB8-4753-BBDD-30AAD391C4DC@consulintel.es>
Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6"
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>
In-Reply-To: <CFFE746A-35C6-4236-9ECC-EF1E6222BFD7@delong.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3666853375_1296374745"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/hiTYyz8OoCOix7A9ot1Tnptx8Lc>
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: Thu, 12 Mar 2020 09:23:07 -0000

Hi Owen,

Using +++ below …

 

 

El 10/3/20 21:49, "v6ops en nombre de Owen DeLong" <v6ops-bounces@ietf.org en nombre de owen@delong.com> escribió:

 

 



On Mar 10, 2020, at 11:25 , JORDI PALET MARTINEZ <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 en nombre de owen@delong.com> escribió:

 

 




On Mar 9, 2020, at 01:42 , JORDI PALET MARTINEZ <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 en nombre de 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.

 


If a Federal office decides to have its DC with IPv6-only, then IPv4-only users will not be able to access it. In that case the DC must use, for example SIIT-DC. That will mean that the DC (internally) is IPv6-only, but the DC-to-Internet is dual-stack, in order to be able to use SIIT-DC.

 

I believe that _IS_ the intent (no support for SIIT/NAT64/etc.).

 

Remember, this is referring to the INTERNAL networks of the federal government agencies… Not the public-facing networks.

 

Unless I misread the memo, the intent is to preserve dual-stack functionality on public-facing services, but ensure that there are no remaining IPv4 dependencies in providing those services over IPv6.

 

Furthermore, footnote 5, “Note that for public Internet services, maintaining viable IPv4 interfaces and transition mechanisms at the edge of service infrastructure may be necessary for additional time, but this does not preclude operating the backend infrastructure as IPv6-only.” Is precisely saying that.

 

Correct.

 


It may happen that some of the LANs in the Federal office itself, are dual-stack still. Otherwise, employees will not be able to use Internet resources that don’t work well with NAT64+DNS64, for example, web sites or apps that use literal IPv4-addresses and are out of the control of the Federal office. So, in this case they still need to use IPv4aaS.

 

That’s not the desired outcome in this process.

 

Indeed, my impression is that the government is, through this memo, intending to put suppliers and web sites on notice that if they do not have IPv6 accessibility they are likely to lose their government customers.

 

I see that as a good thing.

 

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

 

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.

 

If some employe can’t surf their favorite mom-and-pop cat video site while they are supposed to be working for their taxpayer supported salary, I won’t actually be upset.

 

+++  Fully agree!

 

So from my perspective, this memo puts government contractors on notice that their network-based systems providing services to the federal government damn well better fully support IPv6 in the next few years, or they’re going to experience an increasing level of disconnect followed by a very likely contract termination. I see this as a good thing.

 

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

 

Owen

 

_______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops 



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