From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "ams-iport-2.cisco.com", Issuer "Cisco SSCA2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 73F5A21F1BB for ; Wed, 12 Jun 2013 03:10:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFADNIuFGQ/khR/2dsb2JhbABZgwkwvyJ/FnSCIwEBBAF5BQsLDjhXBogbBgy6D48QMweCf2EDmGmQGYMROg X-IronPort-AV: E=Sophos;i="4.87,851,1363132800"; d="scan'208";a="83293497" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 12 Jun 2013 10:10:18 +0000 Received: from dhcp-10-61-98-253.cisco.com (dhcp-10-61-98-253.cisco.com [10.61.98.253]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5CAAFIu017446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Jun 2013 10:10:16 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <51B8462A.9070003@openwrt.org> Date: Wed, 12 Jun 2013 12:10:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <146E938D-0FCD-4F24-9C1E-CB74C98E2617@employees.org> References: <51B82AB8.3090204@openwrt.org> <51B8462A.9070003@openwrt.org> To: Steven Barth X-Mailer: Apple Mail (2.1508) 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 10:10:22 -0000 Steven, > it sounds similar, however its probably a more simplified version for = now. >=20 > 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. right, as long as you also install RFC4191 MSR routes into the correct = table per upstream I think you'll have the exact same behaviour as = described in the draft. > 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. Markus has done that in the IETF homenet project. but the Linux multiple = routing table support either needs to be extended for full support, or = routes must be duplicated among tables. > 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. splendid! really good to see progress on IPv6 support in openwrt. cheers, Ole