Re: [v4tov6transition] Ways to break IPv6

Ed Jankiewicz <> Wed, 13 October 2010 14:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 672E83A6B86 for <>; Wed, 13 Oct 2010 07:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.563
X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XhsJ-SdlI4Lk for <>; Wed, 13 Oct 2010 07:14:36 -0700 (PDT)
Received: from (newmail.SRI.COM []) by (Postfix) with ESMTP id 8C2FF3A6973 for <>; Wed, 13 Oct 2010 07:12:38 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Received: from [] ([unknown] []) by (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <> for; Wed, 13 Oct 2010 07:13:53 -0700 (PDT)
Message-id: <>
Date: Wed, 13 Oct 2010 10:13:52 -0400
From: Ed Jankiewicz <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100915 Thunderbird/3.1.4
To: Joel Jaeggli <>
References: <> <>
In-reply-to: <>
Cc: "" <>
Subject: Re: [v4tov6transition] Ways to break IPv6
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Oct 2010 14:14:47 -0000

  Good point, Joel, the future is now.  Some  recognize that IPv6 is 
already here, others see it sometime in the distant future.  Operational 
and security gaps arise from incompatible assumptions.

I haven't investigated what happened between versions of the network 
security package I use, but it looks like it went from "don't care" 
about IPv6, to block all (by default).  It does permit turning off that 
firewall rule, so I can set it back to ignorance like the previous 
version.  Sort of still leaves me without an IPv6 firewall at the 
moment, but no worse than it was before, and I'm just an experimental user.

It does seem that security products, especially those for end-user 
systems, are particularly behind the curve with IPv6 support.

On 10/13/2010 2:49 AM, Joel Jaeggli wrote:
> I love how we talk about what they will do in the future tense. They do this today. my corporate laptops have had v6 broken in various sundry ways by bad policy and retarded security products across three employers since 2007. As long as v6 has been enabled in systems  people have been disabling it deliberately, or worse, breaking it in ways that make you wonder how these companies keep v4 working, in point of fact sometimes they don't.
> Joel's widget number 2
> On Oct 12, 2010, at 19:40, Ed Jankiewicz<>  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.
>> -- 
>> Ed Jankiewicz - SRI International
>> Fort Monmouth Branch Office - IPv6 Research
>> Supporting DISA Standards Engineering Branch
>> 732-389-1003 or
>> _______________________________________________
>> v4tov6transition mailing list

Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or