IETF Logo Mail Archive

Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

"STARK, BARBARA H" <bs7652@att.com> Tue, 10 December 2019 14:04 UTC

Return-Path: <bs7652@att.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 6AC8C1200B7; Tue, 10 Dec 2019 06:04:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Level:
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 AOqd09C-etQW; Tue, 10 Dec 2019 06:04:01 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 D8A441200B6; Tue, 10 Dec 2019 06:04:01 -0800 (PST)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xBAE0lWU030540; Tue, 10 Dec 2019 09:03:54 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2wsxpffeh4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Dec 2019 09:03:53 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id xBAE3qAt029893; Tue, 10 Dec 2019 09:03:52 -0500
Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id xBAE3lZb029775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Dec 2019 09:03:48 -0500
Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 69D01400A0A3; Tue, 10 Dec 2019 14:03:47 +0000 (GMT)
Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30487.vci.att.com (Service) with ESMTPS id 54DD5400A0A2; Tue, 10 Dec 2019 14:03:47 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.43]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0468.000; Tue, 10 Dec 2019 09:03:47 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Lorenzo Colitti' <lorenzo=40google.com@dmarc.ietf.org>, 'Tomek Mrugalski' <tomasz.mrugalski@gmail.com>
CC: "'draft-link-dhc-v6only@ietf.org'" <draft-link-dhc-v6only@ietf.org>, 'V6 Ops List' <v6ops@ietf.org>, "'dhcwg@ietf.org'" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] IPv6-Only Preferred DHCPv4 option
Thread-Index: AQHVrviyNnjuBtjdnEKBlEHMXYbjcaey7X6AgAB01rA=
Date: Tue, 10 Dec 2019 14:03:46 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61153706A13@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com> <da078a21-b606-f0d9-3833-d66b20410853@marples.name> <CAFU7BASdWZv1RTVa5v4thbKPqCrmG886G+hK2J0UoZ3TbELDnw@mail.gmail.com> <b52fdd35-9663-e7df-7303-748a6b3a57ce@marples.name> <CAKD1Yr0vp2gaVRza+wei0qM6T9oN=iu39jRjK-cvhheorgE=Xg@mail.gmail.com> <67155c63-2442-2846-57f2-82fa4da16251@marples.name> <CAKD1Yr3y9eycfenN-t9oU_zgPHEZPy-AVXs3qXkWOBe9UXxVUQ@mail.gmail.com> <a6035aba-cab5-c779-c977-8b1a995eccfd@marples.name> <c4512681-a064-adff-67f2-e26d58186db0@gmail.com> <CAKD1Yr3U7xX4qFy_zMSm33pVTkCn0gqg75Su6MqdEJQEP06toQ@mail.gmail.com>
In-Reply-To: <CAKD1Yr3U7xX4qFy_zMSm33pVTkCn0gqg75Su6MqdEJQEP06toQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.250.71.224]
Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61153706A13GAALPA1MSGUSRBF_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-10_03:2019-12-10,2019-12-10 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 bulkscore=0 phishscore=0 suspectscore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 mlxlogscore=785 mlxscore=0 malwarescore=0 adultscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912100122
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/zrJHvJBZkmsUyg_6ahZkAGPBn9Q>
Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option
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 Dec 2019 14:04:03 -0000

On Tue, Dec 10, 2019 at 10:25 AM Tomek Mrugalski <tomasz.mrugalski@gmail.com<mailto:tomasz.mrugalski@gmail.com>> wrote:
That's a good analogy. Would it be helpful if the V6ONLY_WAIT description was update to say something similar to: "Upon reception of the V6ONLY_WAIT option, the client sets its reverts back to DHCPDISCOVER retransmission and sets its retransmission timer to V6ONLY_WAIT seconds"?

If it sets its retransmission timer to V6ONLY_WAIT seconds, then if the first discover is dropped, will the second one be V6ONLY_WAIT seconds after that? That seems bad. Once the V6ONLY_WAIT timer fires, we want the retransmission interval to be back to a low value, like 1-2 seconds, right?

Perhaps it's poorly named, but it's very much DHCPv4 option. The option is not supposed to affect any IPv6 behavior.

How about calling it what it really is: DISABLEV4?

It's not just "disable IPv4". It's "disable IPv4, because you there's this other thing instead". See https://mailarchive.ietf.org/arch/msg/dhcwg/Xc0yQIXWkKMCLlxhM-Bp0EW0P7w<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_dhcwg_Xc0yQIXWkKMCLlxhM-2DBp0EW0P7w&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=4d24eNHJHAEFS_Y3-CipdZq80gyQxXT1VGfeLc9lkcE&s=UZx2lQrGUCc1rleXnzrXpv8AT2jJ1qNVp4CCn94OpwU&e=> and follow-ups.

<bhs> Is it really “disable IPv4 ...” or “disable DHCPv4 address acquisition for a while”? I thought hosts were still free to use autoconfigured IPv4 addresses (169.254.x.x) on the LAN. I ask because I don’t want to go down that rat-hole of people thinking it might be ok for routers to start blocking everything on the IPv4 ethertype if this option is sent from the router’s DHCPv4 server. We’re just trying to save on DHCPv4 address assignment with this, aren’t we?

v2.23.0 | Report a Bug | By Email