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

Owen DeLong <owen@delong.com> Tue, 10 March 2020 18:03 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 57A1F3A05A4 for <v6ops@ietfa.amsl.com>; Tue, 10 Mar 2020 11:03:00 -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 bV2f14kj6iTY for <v6ops@ietfa.amsl.com>; Tue, 10 Mar 2020 11:02:54 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4413A0780 for <v6ops@ietf.org>; Tue, 10 Mar 2020 11:02:53 -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 02AI2oGT1138855 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 11:02:50 -0700
From: Owen DeLong <owen@delong.com>
Message-Id: <073925C4-5355-4C51-84A4-4D9545013552@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_106B6709-0511-4FF2-9520-2091FDFFED82"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 10 Mar 2020 11:02:50 -0700
In-Reply-To: <B8678AA0-7D7A-4ACD-BB4A-DDEDE85ACB88@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>
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]); Tue, 10 Mar 2020 11:02:51 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/PKCKQZ02xX4wYJ0OFIBSNMhbo6w>
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: Tue, 10 Mar 2020 18:03:00 -0000


> 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 <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.
 
> 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.
 
> external connectivity supporting IPv6. External connectivity that requires connectivity to legacy Internet hosts can be accomplished via appropriate gateway technologies such as NAT64". A provision for "specific applications where IPv6 is not supportable may be able to use internal gateway technologies such as 464XLAT with a plan for migration to support IPv6 natively." These aren't exact quotes, just my suggested ideas, but this seems to capture the spirit of the initiative.

I don’t think that’s the actual spirit of the initiative…

See above.

Owen