Re: IPv4 traffic on "ietf-v6ONLY"

"Rajiv Asati (rajiva)" <> Thu, 16 November 2017 10:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92ED6127909 for <>; Thu, 16 Nov 2017 02:32:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fBFIFCJuJaYj for <>; Thu, 16 Nov 2017 02:32:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 740551200CF for <>; Thu, 16 Nov 2017 02:32:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2098; q=dns/txt; s=iport; t=1510828358; x=1512037958; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=HltDUmPQwRjVMWjkjC2bovg13MurvwOpfWmA4SQlJqs=; b=h9fWOfLKoeg1XyGooDPC53wK+1tQNjuRkv5aMLtwOi/+Aa7P9O3DMTQw jlTwFrvIs0ZCJKjj/NQIRwS/gXQ0iHuxk/P5zvBXUTpBazggF/Xr980h9 SZXt9oEcEKLmkm2JfUYnU2dndf08HP90iDGxTz8t6sF+9x0jE2h5jF9TF I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.44,402,1505779200"; d="scan'208";a="32223848"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2017 10:32:21 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id vAGAWLUc012278 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2017 10:32:21 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 16 Nov 2017 04:32:20 -0600
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Thu, 16 Nov 2017 04:32:20 -0600
From: "Rajiv Asati (rajiva)" <>
To: Philip Homburg <>, "" <>
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
Thread-Topic: IPv4 traffic on "ietf-v6ONLY"
Thread-Index: AQHTXg7aCDuXpAYsgk2hw+GoRJ/sAKMXNNOA
Date: Thu, 16 Nov 2017 10:32:20 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Nov 2017 10:32:41 -0000

While I do agree to RA being better than DHCP(v6) for the purpose discussed here, I also agree with Philip wrt L-flag usage. PvD L-flag = 0 would not prohibit a host from using IPv4 on the access.

We might be better off defining a new flag that explicitly indicates for host to ‘Suppress IPv4’. 


-----Original Message-----
From: ipv6 <> on behalf of Philip Homburg <>
Date: Wednesday, November 15, 2017 at 7:40 AM
To: "" <>
Subject: Re: IPv4 traffic on "ietf-v6ONLY" 

    >There's an L flag in draft-ietf-intarea-provisioning-domains
    >that says "DHCP(v4) on this network". So L=0 says "No DHCP(v4) on
    >this network".
    Maybe I'm reading the draft too strictly, but it seems that the L flag is used
    to tell which provisioning domain DHCPv4 information belongs to. Not to tell
    a host to avoid using DHCPv4 in the first place.
    If it does have the intention to make hosts avoid DHCPv4 requests then it
    has the same drawback as in sending a 'no IPv4' option in RA or DHCPv6:
    in an IPv4-only network that can be used to prevent hosts from connecting to
    the network.
    IETF IPv6 working group mailing list
    Administrative Requests: