From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from chi.subsignal.org (cxd-2-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:ed::2]) by huchra.bufferbloat.net (Postfix) with ESMTP id E283D21F1B5 for ; Wed, 12 Jun 2013 02:58:04 -0700 (PDT) Received: from [192.168.178.21] (unknown [212.255.36.49]) by chi.subsignal.org (Postfix) with ESMTPSA id 8275C126225; Wed, 12 Jun 2013 11:58:47 +0200 (CEST) Message-ID: <51B8462A.9070003@openwrt.org> Date: Wed, 12 Jun 2013 11:58:02 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: Ole Troan References: <51B82AB8.3090204@openwrt.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000104000302030301030906" Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] cerowrt dev 3.8.13-7 released X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 09:58:05 -0000 This is a multi-part message in MIME format. --------------000104000302030301030906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ole, it sounds similar, however its probably a more simplified version for now. As we have DHCPv6-PD as the only officially integrated way of receiving prefixes from upstream routers (and that doesn't really allow to assign prefixes to a specific router) - and all other methods are either static configuration or point-to-point tunnels we currently don't differentiate between different routers on the same upstream-interface. That means we have one routing table per upstream interface. However if anyone is to integrate something like OSPF protocol handlers into netifd which allows to associate source prefixes with routes this will probably be added. For now we just wanted to be as compliant as possible regarding RFC 6204 and 6204-bis12 and we need the source-based routing for generic multiwan and to send out the ingress/egress policy failed stuff. Btw. we backported the new IPv6-stack to Attitude Adjustment as well: See http://wiki.openwrt.org/doc/uci/network6 for our current status, list of features and so on. Cheers, Steven On 12.06.2013 11:38, Ole Troan wrote: > Steven, > >> Source-based IPv6 routing was introduced a few weeks ago to properly support multiple IPv6 uplink-interfaces. Therefore OpenWrt only let's you route through the tunnel if it knows you have a suitable source address. > out of curiosity, is this SADR as described in http://tools.ietf.org/html/draft-troan-homenet-sadr-00? > > cheers, > Ole --------------000104000302030301030906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Ole,

it sounds similar, however its probably a more simplified version for now.

As we have DHCPv6-PD as the only officially integrated way of receiving prefixes from upstream routers (and that doesn't really allow to assign prefixes to a specific router) - and all other methods are either static configuration or point-to-point tunnels we currently don't differentiate between different routers on the same upstream-interface.
That means we have one routing table per upstream interface.

However if anyone is to integrate something like OSPF protocol handlers into netifd which allows to associate source prefixes with routes this will probably be added. For now we just wanted to be as compliant as possible regarding RFC 6204 and 6204-bis12 and we need the source-based routing for generic multiwan and to send out the ingress/egress policy failed stuff.


Btw. we backported the new IPv6-stack to Attitude Adjustment as well:
See http://wiki.openwrt.org/doc/uci/network6 for our current status, list of features and so on.


Cheers,

Steven



On 12.06.2013 11:38, Ole Troan wrote:
Steven,


Source-based IPv6 routing was introduced a few weeks ago to properly support multiple IPv6 uplink-interfaces. Therefore OpenWrt only let's you route through the tunnel if it knows you have a suitable source address.

out of curiosity, is this SADR as described in http://tools.ietf.org/html/draft-troan-homenet-sadr-00?

cheers,
Ole

--------------000104000302030301030906--