Re: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis

Lee Howard <lee@asgard.org> Mon, 21 August 2017 13:50 UTC

Return-Path: <lee@asgard.org>
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 4261513235C for <v6ops@ietfa.amsl.com>; Mon, 21 Aug 2017 06:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham 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 tEmD2A7_ZXJF for <v6ops@ietfa.amsl.com>; Mon, 21 Aug 2017 06:50:30 -0700 (PDT)
Received: from atl4mhob07.registeredsite.com (atl4mhob07.registeredsite.com [209.17.115.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D86124207 for <v6ops@ietf.org>; Mon, 21 Aug 2017 06:50:30 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob07.registeredsite.com (8.14.4/8.14.4) with ESMTP id v7LDoRld019798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <v6ops@ietf.org>; Mon, 21 Aug 2017 09:50:27 -0400
Received: (qmail 30769 invoked by uid 0); 21 Aug 2017 13:50:27 -0000
X-TCPREMOTEIP: 68.100.68.25
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 21 Aug 2017 13:50:27 -0000
User-Agent: Microsoft-MacOutlook/14.7.2.170228
Date: Mon, 21 Aug 2017 09:50:24 -0400
From: Lee Howard <lee@asgard.org>
To: "STARK, BARBARA H" <bs7652@att.com>, "jordi.palet@consulintel.es" <jordi.palet@consulintel.es>, "v6ops@ietf.org" <v6ops@ietf.org>
Message-ID: <D5C05AB8.82116%lee@asgard.org>
Thread-Topic: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis
References: <A2F465E7-51A9-4353-80DB-262DB861F653@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DBFF3F3@GAALPA1MSGUSRBF.ITServices.sbc.com> <937FEB7C-AC79-4E06-80EC-C8CBE91B3EF7@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DBFF7BB@GAALPA1MSGUSRBF.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBFF7BB@GAALPA1MSGUSRBF.ITServices.sbc.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ohPPnefwoH6AelSUD2IKw04DRus>
Subject: Re: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 21 Aug 2017 13:50:32 -0000


On 8/16/17, 5:32 PM, "v6ops on behalf of STARK, BARBARA H"
<v6ops-bounces@ietf.org on behalf of bs7652@att.com> wrote:

>Inline...
>Barbara
>
>> draft-ietf-sunset4-gapanalysis-09, problems 1-5, refer to the case when
>>IPv4
>> is no longer available.
>
>Yes: Not available (through any means) on the WAN. But still used on the
>LAN.

Problem 1 applies both to a home router and a LAN client interpreting a
lack of DHCP response as an error. I don’t think this needs to be separate
problems for router and device, do you?
Problem 2 is for when IPv4 is not available on the WAN but the router
advertises DHCP to the LAN.
Problems 3-5 (Section 2.2) "Disabling IPv4 in the LAN” are not about when
it’s still used on the LAN.

>
>> So, if RFC7084 is an IPv6 only-CE (even if the CE can have an IPv4
>>stack), then
>> we have those problems when there is no IPv4 connectivity.
>
>Yes: We will have the described problems if there is no IPv4 available on
>the WAN (through any means).
>
>> If the IPv6-CE supports transition, then you never have those problems,
>> because the goal of the transition support is precisely to avoid them.
>>It is not
>> a matter of IPv4 in the WAN. You can have IPv6-only WAN, but transition
>>can
>> resolve that.
>> 
>> Or I’m missing anything in your opinion?
>
>Please correct me if I'm wrong, but I thought all the described
>mechanisms require a correlated capability in the WAN. Just because a CE
>router supports all of these doesn't mean any of them necessarily exist
>in the WAN, or that configuration of any of them via DHCPv6 is supported
>by the ISP (WAN may have capability but requires manual CE Router config
>which many end users won't know how to do). So I think support in the CE
>Router, by itself, is insufficient to ensure IPv4 WAN availability.
>Therefore, even if a CE Router supports all of these, it is still
>possible for there to be no IPv4 WAN connection. IMO, CE Router
>requirements that explicitly target IPv6-only operation would be a very
>logical place to include requirements for "what to do when there is no
>IPv4 in the WAN".

This makes sense to me, though I might amend it to, "what to do when there
is no native IPv4 or IPv4 transition mechanism in the WAN”

>
>> The problem here, in my opinion is that in the actual RFC7084 you
>>“allow” the
>> support of IPv4, so is in that case when, if there is no transition
>>support, the
>> problems 1-5 may be presented in the LANs.
>> 
>> So, one alternative is again considering my proposal of making an
>>RFC7084
>> with is “really” only-IPv6 (removing ALL the IPv4 support in that
>>document),
>> and then it make sense to have other documents with the transition
>>support,
>> etc., and then finding the right one for resolving the problems above.
>
>Because of the existence of the CE Router IPv6 Ready certification
>program, the many references to RFC 7084 made by external orgs, etc. I
>continue to be opposed to changing it. That would almost certainly cause
>confusion, and is unnecessary. Requirements related to IPv6-only WAN
>connections (with or without the WAN supporting configuration or
>termination of an IPv4 tunneling mechanism) can all logically go in a
>single new doc.
>
>> Actually, some of the problems, in my opinion, can be resolved just in
>>the OS,
>> but is not a matter here to discuss one by one. For example, problem 1,
>> some OS may believe there is only “Internet” if there is a DHCP server
>> responding, even if they have IPv6 connectivity, etc., but this can be
>>sorted
>> out in the actual RFC7084 if there is IPv4 stack, and there is no
>>transition
>> support and there is not IPv4 support, by making sure that the DHCPv4
>> server in the CE is not turned on in that case …
>
>That's a bad idea. I expect my home network to operate in the absence of
>any and all WAN IP connections. I refuse to buy (or sell or recommend) a
>CE router that does not continue to operate its DHCPv4 server in the
>absence of IPv4 WAN connectivity. Also, I disagree with putting any
>LAN-side IPv4 protocol requirements into a 7084bis.

I no longer need IPv4 in my home network, except in translation.
Can’t I just turn it off? If I can, even if it’s manual, then what happens?
I realize the fallacy of assuming I’m a typical user, but in three years
when 80% of US connections are IPv6, aren’t we thinking seriously about it?

Lee