Re: [v6ops] Please review the No IPv4 draft

Ray Hunter <v6ops@globis.net> Thu, 17 April 2014 08:55 UTC

Return-Path: <v6ops@globis.net>
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 490231A00FE for <v6ops@ietfa.amsl.com>; Thu, 17 Apr 2014 01:55:28 -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 Rwd-ieHTf6oS for <v6ops@ietfa.amsl.com>; Thu, 17 Apr 2014 01:55:26 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id AE4911A0027 for <v6ops@ietf.org>; Thu, 17 Apr 2014 01:55:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9AA6E870073; Thu, 17 Apr 2014 10:55:22 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwURrh2KG8lz; Thu, 17 Apr 2014 10:55:22 +0200 (CEST)
Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:a5d1:d231:56c8:a9ec]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 5AFAB87006F; Thu, 17 Apr 2014 10:55:22 +0200 (CEST)
Message-ID: <534F96F7.3030806@globis.net>
Date: Thu, 17 Apr 2014 10:55:19 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.9 (Macintosh/20140129)
MIME-Version: 1.0
To: Mikael Abrahamsson <swmike@swm.pp.se>
References: <534BF5A5.5010609@viagenie.ca> <20140415083615.GB43641@Space.Net> <534D3672.3060702@viagenie.ca> <3446106.k0lm12lQ8b@linne> <alpine.DEB.2.02.1404161034220.10236@uplift.swm.pp.se> <CAKD1Yr2D+ZMi-UctuvrMzyqoHqgBy5O26GODT=bRwq0PsvLgLw@mail.gmail.com> <alpine.DEB.2.02.1404161053110.10236@uplift.swm.pp.se> <20140416155714.GB64039@ricotta.doit.wisc.edu> <alpine.DEB.2.02.1404162310050.10236@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1404162310050.10236@uplift.swm.pp.se>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wWvex5vx9IGB3mTmSgfwhVqBbBc
Cc: "v6ops@ietf.org WG" <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: Thu, 17 Apr 2014 08:55:28 -0000

Mikael Abrahamsson wrote:
> On Wed, 16 Apr 2014, Dale W. Carder wrote:
>
>> So, I am not in favor of adding more hints that may or may not 
>> observed that result in additional complexity and create an even more 
>> diverse set of behavior that has to be managed.  This is why I think 
>> the only real solution that would work in practice is ethertype 
>> filtering.
+1
>
> That still doesn't solve the problem of the enterprise network being 
> IPv6 only but publishes A and AAAA entries for internal resources on 
> the internal DNS zone, because other networks they have are dual stack.
>
> Otoh I think this would be better solved by implementing MIF 
> functionality in the device but... oh well.
>
Enterprise networks will use alternative protocols/methods to configure 
their end nodes IMHO e.g. Active Directory

And we have https://tools.ietf.org/html/rfc7078 for cases where some 
LANs are IPv4 only, some are dual stack, and others are IPv6 only 
(assuming anyone implements it)

I'm hoping that a node connected to an authenticated AD server will by 
default ignore any unauthenticated configuration hints purportedly sent 
via a DHCPv6 server.

Although as I've pointed out earlier, there could be serious race 
conditions here (RA/DHCPv6 IPv4 shutdown packet of death arrives before 
AD authentication).

-- 
Regards,
RayH