Re: IPv6 traffic stats

Pekka Savola <pekkas@netcore.fi> Thu, 13 November 2008 12:24 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE083A6864; Thu, 13 Nov 2008 04:24:27 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E713A6864 for <ietf@core3.amsl.com>; Thu, 13 Nov 2008 04:24:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_27=0.6]
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 hxcg8AhZ2ny1 for <ietf@core3.amsl.com>; Thu, 13 Nov 2008 04:24:25 -0800 (PST)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 33BEF3A681D for <ietf@ietf.org>; Thu, 13 Nov 2008 04:24:24 -0800 (PST)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id mADCOHjJ015324; Thu, 13 Nov 2008 14:24:17 +0200
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id mADCOHPX015321; Thu, 13 Nov 2008 14:24:17 +0200
Date: Thu, 13 Nov 2008 14:24:17 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Subject: Re: IPv6 traffic stats
In-Reply-To: <15E4B4A6-45BE-4CB3-9C2B-F1C36C10BD66@muada.com>
Message-ID: <alpine.LRH.2.00.0811131418310.15111@netcore.fi>
References: <08111108201165.2a71d.487911088@oregon.uoregon.edu> <20081111185711.GG1588@nsn.com> <4919ED2F.2020101@alvestrand.no> <f1110c510811111249ud4ee387m2169fb84378ec3f4@mail.gmail.com> <4919FA68.4030803@alvestrand.no> <alpine.LRH.2.00.0811120747470.11163@netcore.fi> <491AAAAB.6000209@alvestrand.no> <alpine.LRH.2.00.0811122118050.28713@netcore.fi> <15E4B4A6-45BE-4CB3-9C2B-F1C36C10BD66@muada.com>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on otso.netcore.fi
X-Virus-Status: Clean
Cc: IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Wed, 12 Nov 2008, Iljitsch van Beijnum wrote:
> In my opinion, this is a bug. This is the default policy table from a FreeBSD 
> system, which is the RFC 3484 table IIRC:

You should probably bring this up on 6MAN WG list then.

>>  ip6addrctl
> Prefix                          Prec Label      Use
> : : 1/128                           50     0        0
> : :/0                              40     1   646064
> 2002::/16                         30     2        0
> : :/96                             20     3        0
> : : ffff:0.0.0.0/96                 10     4        0
>
> The last line catches IPv4. It's two steps below the 6to4 prefix. However, 
> the fact that the label for the 6to4 prefix doesn't match the ::/0 label 
> means that IPv4 will be used.
>
> This happens on FreeBSD and XP, and I assume also on Vista. But not on MacOS, 
> because it doesn't implement the policy table. I don't know about Linux. (If 
> you want to test, try to connect to 6to4test.runningipv6.net and see what 
> happens. Both addresses are unreachable, though.)

I'm not sure whether you're agreeing with me or something else; I 
don't see where you're saying the bug is.  But if we start talking 
about issues in RFC3484, it should happen on 6MAN list.

Your test is inconclusive due to the fact that the A record is a 
private address.  Depending on whether the connecting host has a 
global or private address, the results are different (see my mail to 
Remi for more).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf