IETF Logo Mail Archive

Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line..

Daniel Roesen <dr@cluenet.de> Fri, 05 August 2011 12:44 UTC

Return-Path: <dr@cluenet.de>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBD821F8B15 for <v6ops@ietfa.amsl.com>; Fri, 5 Aug 2011 05:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSSzM0swI5PA for <v6ops@ietfa.amsl.com>; Fri, 5 Aug 2011 05:44:01 -0700 (PDT)
Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id C279321F8AF7 for <v6ops@ietf.org>; Fri, 5 Aug 2011 05:44:00 -0700 (PDT)
Received: by mail1.cluenet.de (Postfix, from userid 500) id 176A81080A2; Fri, 5 Aug 2011 14:44:17 +0200 (CEST)
Date: Fri, 05 Aug 2011 14:44:17 +0200
From: Daniel Roesen <dr@cluenet.de>
To: v6ops@ietf.org
Message-ID: <20110805124417.GA16338@srv03.cluenet.de>
Mail-Followup-To: v6ops@ietf.org
References: <4E3A4994.4060606@globis.net> <2A58D1AC-5AFE-4118-BFC3-3C5FE1F5063C@apnic.net> <20110804092031.GA26186@srv03.cluenet.de> <A15F295A-654A-43E1-BEC0-676D46576F45@apnic.net> <24FAA902-28E9-4A50-B7B8-2E958D20F897@nominet.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <24FAA902-28E9-4A50-B7B8-2E958D20F897@nominet.org.uk>
User-Agent: Mutt/1.5.17 (2007-11-01)
Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line..
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 05 Aug 2011 12:44:01 -0000

On Fri, Aug 05, 2011 at 10:28:47AM +0000, Ray Bellis wrote:
> Perhaps we should repurpose the IPv4 evil bit as an indication
> of a path that is not "end-to-end" transparent ;-)

Actually, OSX could source packets with the evil bit set, so operators
can introduce additional biasing delay only for those packets and don't
impare users of less selfish, short-sighted networking stacks. :-)

> "An IPv4 NATing device MUST set the evil bit on all packets to which
> it has applied NAT.  All else being equal, a client SHOULD prefer an
> IPv6 path over an IPv4 path that has the evil bit set."
> 
> [only half kidding]

Indeed only half kidding. SYN-ACK marking in some magic way perhaps?

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

v2.23.0 | Report a Bug | By Email