From owner-freebsd-net@FreeBSD.ORG Fri Apr 6 11:20:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAA1E106566C for ; Fri, 6 Apr 2012 11:20:38 +0000 (UTC) (envelope-from seth.mos@dds.nl) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by mx1.freebsd.org (Postfix) with ESMTP id 63AD88FC0C for ; Fri, 6 Apr 2012 11:20:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 0EEDE58BB5 for ; Fri, 6 Apr 2012 13:20:31 +0200 (CEST) Received: from [10.0.2.53] (edge-pf.coltex.nl [91.227.27.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 479E95879E for ; Fri, 6 Apr 2012 13:20:26 +0200 (CEST) Message-ID: <4F7ED1C1.7050903@dds.nl> Date: Fri, 06 Apr 2012 13:21:37 +0200 From: Seth Mos User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4F74755A.2040308@dds.nl> <4F794D1A.7020307@dds.nl> In-Reply-To: <4F794D1A.7020307@dds.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3 at rotring X-Virus-Status: Clean Subject: Re: 6rd status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 11:20:38 -0000 Op 2-4-2012 8:54, Seth Mos schreef: > Op 29-3-2012 16:44, Seth Mos schreef: >> Hi, >> > Only to reply to myself here, I've not seen response yet. Replying to myself again. I confirm that the 6rd patch to stf from hrs@ indeed works as advertised. The Charter and Sakura 6rd relays do not employ filtering which means these can be used from everywhere in the world. Sakura is about 500ms and Charter about 200ms from where I tested which limits the usability. One that thing that must be noted is that the patch does not support RFC5969 Standards track support 6rd. This uses a variable length for both the 6rd prefix and the v4 prefix length as long as it fits in the left 64 bits. From the RFC. http://tools.ietf.org/html/rfc5969 | n bits | o bits | m bits | 128-n-o-m bits | +---------------+--------------+-----------+------------------------+ | 6rd prefix | IPv4 address | subnet ID | interface ID | +---------------+--------------+-----------+------------------------+ |<--- 6rd delegated prefix --->| There is a dutch ISP rolling out with a 6rd prefix of 41 bits and a IPv4 prefix length of 17 bits resulting in a /56 delegated prefix for each user. (41 + (32 - 17)) = 56 The current 6rd patch does not provide such a facility from my limited testing. Theoretically it might work providing the IPv6 prefix and gateway are calculated with that math in mind. But I don't have the network to confirm this. This might be easy to support. Regards, Seth