Re: [v6ops] Please review the No IPv4 draft

"Dale W. Carder" <dwcarder@wisc.edu> Tue, 15 April 2014 14:21 UTC

Return-Path: <dwcarder@wisc.edu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EEB1A01D4 for <v6ops@ietfa.amsl.com>; Tue, 15 Apr 2014 07:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.173
X-Spam-Level:
X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham
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 kxqpyv1F9vu1 for <v6ops@ietfa.amsl.com>; Tue, 15 Apr 2014 07:21:08 -0700 (PDT)
Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) by ietfa.amsl.com (Postfix) with ESMTP id CD8341A00CF for <v6ops@ietf.org>; Tue, 15 Apr 2014 07:21:08 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-disposition: inline
Content-type: text/plain; CHARSET="US-ASCII"
Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0N4200H00SZZX300@smtpauth4.wiscmail.wisc.edu> for v6ops@ietf.org; Tue, 15 Apr 2014 09:21:05 -0500 (CDT)
X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.15.141221, SenderIP=0.0.0.0
Received: from ricotta.doit.wisc.edu (ricotta.doit.wisc.edu [144.92.67.161]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N42003O6T732S20@smtpauth4.wiscmail.wisc.edu>; Tue, 15 Apr 2014 09:21:04 -0500 (CDT)
Date: Tue, 15 Apr 2014 09:21:03 -0500
From: "Dale W. Carder" <dwcarder@wisc.edu>
To: Simon Perreault <simon.perreault@viagenie.ca>
Message-id: <20140415142103.GA50776@ricotta.doit.wisc.edu>
References: <534BF5A5.5010609@viagenie.ca>
In-reply-to: <534BF5A5.5010609@viagenie.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Iwflwa9hu9xF880GeQxyvosS5Vg
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Please review the No IPv4 draft
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 15 Apr 2014 14:21:13 -0000

Thus spake Simon Perreault (simon.perreault@viagenie.ca) on Mon, Apr 14, 2014 at 10:50:13AM -0400:
> Dearest V6OPS,
> 
> We are soliciting reviews for this SUNSET4 draft:
> 
> http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00
> 
> In a nutshell, it defines DHCPv6 and RA options indicating to the host
> that IPv4 is not available. Reviews from operations-minded people in
> V6OPS would be of tremendous help.

I guess I am still confused by your use cases.  In looking at our dhcpv4 
servers, I don't have No-IPX nor No-AppleTalk options sent to clients,
so I am confused why this is needed for IPv4.

3.1:  Turn off the dhcpv4 relay feature per router (sub)interface.  No more 
load on the dhcpv4 server.

3.2:  At the edge of your network, filter packets containing ethertypes you 
do not support.  

3.3:  Mobile device vendors have an incentive in fixing their code so
they do not chew up their battery more than their competitors.

3.4:  At the edge of your network, filter packets containing ethertypes you 
do not support.

I think I understand 5.3 however I think you made a much better argument for 
turning off dhcp relay and ethertype filtering.  The v4-level just says
where the filter would best be configured.

Since not every host would understand the No_IPv4 option, you are probably 
just going to have to filter in your network anyway if Section 3 is truly 
a problem.

Dale