Re: [v4tov6transition] Ways to break IPv6

"Yiu L. Lee" <yiu_lee@cable.comcast.com> Wed, 13 October 2010 02:44 UTC

Return-Path: <yiu_lee@cable.comcast.com>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ABD13A6B30 for <v4tov6transition@core3.amsl.com>; Tue, 12 Oct 2010 19:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.453
X-Spam-Level:
X-Spam-Status: No, score=-104.453 tagged_above=-999 required=5 tests=[AWL=1.943, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75LbAeHfHlEB for <v4tov6transition@core3.amsl.com>; Tue, 12 Oct 2010 19:44:43 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 845C83A68BA for <v4tov6transition@ietf.org>; Tue, 12 Oct 2010 19:44:43 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.98357738; Tue, 12 Oct 2010 22:45:56 -0400
Received: from PACDCEXCMB04.cable.comcast.com (24.40.15.86) by pacdcexhub03.cable.comcast.com (24.40.55.40) with Microsoft SMTP Server id 14.1.218.12; Tue, 12 Oct 2010 22:45:56 -0400
Received: from 68.81.91.8 ([68.81.91.8]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server legacywebmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Wed, 13 Oct 2010 02:45:56 +0000
User-Agent: Microsoft-Entourage/12.26.0.100708
Date: Tue, 12 Oct 2010 22:45:54 -0400
From: "Yiu L. Lee" <yiu_lee@cable.comcast.com>
To: Ed Jankiewicz <edward.jankiewicz@sri.com>, <v4tov6transition@ietf.org>
Message-ID: <C8DA95A2.3F081%yiu_lee@cable.comcast.com>
Thread-Topic: [v4tov6transition] Ways to break IPv6
Thread-Index: ActqgME0Uv8KYj0/X0SRYP1X9adDgw==
In-Reply-To: <4CB51C1D.7040104@sri.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [v4tov6transition] Ways to break IPv6
X-BeenThere: v4tov6transition@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6transition@ietf.org>
List-Help: <mailto:v4tov6transition-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2010 02:44:44 -0000

This is expected behavior. Since IPv6 provides e2e connectivity, this is
required to enable FW by default. I think the FW is doing the right thing.
Despite the correct behavior, this will create a lot of confusion in the
beginning of launching IPv6. Education is needed to train the users to
realize the changes and this isn't going to be easy.


On 10/12/10 10:40 PM, "Ed Jankiewicz" <edward.jankiewicz@sri.com> wrote:

> 
>   this is not a surprise, it is something that has been predicted by
> many as one of the "growing pains" of IPv6 transition.  Firewalls and
> other security software will "support" IPv6 initially by just blocking
> it - too much work (and too little demand) for a real implementation.
> 
> Just loaded an updated version of the commercial anti-virus package that
> I've been using, let it remain nameless, it is certainly not the only
> offender in this area.  Unlike the previous version this includes an
> enhancement - it blocks all IPv6 and IPv6 over IPv4 traffic by default.
> The firewall rule can be disabled.
> 
> If you are a network operator, there is a lot of mischief that can be
> done by software that the end-user downloads onto their machines that
> can make IPv6 appear broken.  This is another area that should get some
> attention - how will customer service and help desk people be trained to
> deal with "connectivity" problems the user can cause themselves?
> 
> It took me a while to figure this out, and I'm one of the people who
> frequently predicted this would happen.  Imagine your average end-user
> who knows nothing about IPv6 and expects that "it just works".  Also,
> many books, websites and other security advice says "when in doubt, turn
> off IPv6".  At least in the foreseeable future, this will continue to be
> impedance against the uptake of IPv6.
>