From owner-freebsd-net@FreeBSD.ORG Fri Sep 24 06:15:32 2010 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53E5B1065672 for ; Fri, 24 Sep 2010 06:15:32 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9588FC14 for ; Fri, 24 Sep 2010 06:15:31 +0000 (UTC) Received: from alph.d.allbsd.org (p2176-ipbf406funabasi.chiba.ocn.ne.jp [124.86.72.176]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.3) with ESMTP id o8O6FD1u023081; Fri, 24 Sep 2010 15:15:23 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.4/8.14.4) with ESMTP id o8O6F389019116; Fri, 24 Sep 2010 15:15:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 24 Sep 2010 15:14:29 +0900 (JST) Message-Id: <20100924.151429.153301331.hrs@allbsd.org> To: loki.fab@gmail.com From: Hiroki Sato In-Reply-To: References: <20100923.053236.231630719.hrs@allbsd.org> <20100924.011518.142217958.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Sep_24_15_14_29_2010_101)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Fri, 24 Sep 2010 15:15:26 +0900 (JST) X-Spam-Status: No, score=-99.3 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, RCVD_IN_PBL, SPF_SOFTFAIL, USER_IN_WHITELIST, X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: net@FreeBSD.org Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(4) 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, 24 Sep 2010 06:15:32 -0000 ----Security_Multipart(Fri_Sep_24_15_14_29_2010_101)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ondoy wrote in : lo> I haven't tried your patch yet but I need some clarifications. lo> RFC 5969 has the following elements for 6rd configuration: lo> IPv4MaskLen, 6rdPrefix, 6rdPrefixLen, 6rdBRIPv4Address. lo> lo> >From your example, I think the following takes care of lo> 6rdPrefix and 6rdPrefixLen: lo> # ifconfig stf0 inet6 2001:db8:c000:0202::/32 lo> lo> How can we configure the IPv4MaskLen and 6rdBRIPv4Address? 6rdBRIPv4Address is a part just after prefixlen of an IPv6 address on the stf. In the case of 2001:db8:c000:0202::/32, it is c000:0202 = 192.0.2.2. When a host wants to communicate with a BR router, just specifying an IPv6 address with embedded BR IPv4 address is fine. No configuration of stf on that host is needed. lo> I suspect IPv4MaskLen is fixed at zero (use all 32 bits) in this patch.(?) IPv4MaskLen can be set in the IPv6 routing table, not stf interface itself. The stf interface accepts 6rd IPv4 packet with a whole IPv4 source address range (this is equivalent to IPv4MaskLen=0 here) once, but it delivers the decapsulated IPv6 packet with a valid route only. So, if no route in 2001:db8::/32 which is more specific is added, no IPv6 packet is delivered outside of the stf. For example, the router has a route 2001:db8:c000:0200::/56 to outside of the stf, IPv4MaskLen is virtually equal to /24. lo> As I understand from the specs, this can be variable. lo> It seems that at the CE, the IPv4 address of the BR is automatically lo> calculated from the dst/src IPv6 address. But what if the embedded lo> IPv4 address is not the whole 32 bits (IPv4MaskLen > 0)? lo> lo> Also, you mentioned that prefixlen of stf is from 0 to 32. Is this lo> the same as 6rdPrefixLen? lo> I think 6rdPrefixLen can be more than 32. No, 6rdPrefixLen is implemented as "stf's prefixlen + 32" in the patch. So, the range is from 32 to 64 in terms of 6rdPrefixLen. In short, a prefix with IPv4MaskLen=0 is always set to the stf, and IPv4MaskLen is handled in the routing table. Yes, I agree that this is a bit confusing and maybe I will change the design and/or the way to configure it in more intuitive fashion. It is due to some limitations in the internal structure of stf. lo> Lastly, I'm a bit confused with the IPv6 default route at the CE lo> (set to 2001:db8:c000:0201::1) since there's supposed to be lo> no IPv6 connection between the CE and the BR, only IPv4. It works like following: the CE router has a route to 2001:db8::/32 on its stf, so an IPv6 packet with no direct IPv6 connection goes to stf, then it will be encapsuled as a 6rd IPv4 packet, delivered to the BR via IPv4, and decapsuled there. The IPv4 address of the BR is embedded in that address. -- Hiroki ----Security_Multipart(Fri_Sep_24_15_14_29_2010_101)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkycQcUACgkQTyzT2CeTzy1chQCg1hH5IY1Yj2CGHFkkjHyEJ/Hd 9swAniPnVJgEGaVQWkjlp6AFTM58M2dV =KGtA -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Sep_24_15_14_29_2010_101)----