From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mtv-iport-3.cisco.com", Issuer "Cisco SSCA2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 14774200203 for ; Tue, 11 Dec 2012 13:02:36 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAHABifx1CrRDoG/2dsb2JhbABEg0i7BhZzgh4BAQQBOj8FCwsOOFcGiB4FqymQSJAsYQObcopdgnQ X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="63729940" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 11 Dec 2012 21:02:34 +0000 Received: from [10.61.102.133] (dhcp-10-61-102-133.cisco.com [10.61.102.133]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBBL2VTE032008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Dec 2012 21:02:34 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 11 Dec 2012 22:02:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <21D9A278-EBD5-4148-AA3E-073AC93451B4@employees.org> References: <8F973FF7-B39D-4E21-B889-14F6105A29F4@employees.org> To: Steven Barth X-Mailer: Apple Mail (2.1499) Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Current state of ipv6 in openwrt barrier breaker 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: Tue, 11 Dec 2012 21:02:36 -0000 Steven, > your feedback is appreciated, thanks. > Just to clarify a few things here because I think there might be > misunderstandings. yes, seems like I did (misunderstand that is. ;-)) >> or create state... >> NPT should not be on by default though > I agree and it won't be a default in plain OpenWrt. >=20 >=20 >> I think the the ULA prefix should be created as specified in RFC4193. >> otherwise you'll get into trouble merging networks, or building a >> mesh with your neighbour. >> (overlapping ULA space). > In the current implementation /dev/urandom is used to generate the /48 > on the first boot of the device. fd00:: was just an example here. > I don't see any particular advantage in using the sha / ntp etc. thing > especially since there might not be a working RTC. cool. if you don't want to keep additional state, you could base it on a = MAC address in the box, but random is fine too, as long as it is persistent (across reboots). >> shouldn't all interface have a /64? > I won't restrict users doing anything else but /64 is the default, = yes. ack. >> actually it should not be expected to have global reachability. >> doing ULA to global translation by default would break one of the >> ideas we have in the homenet WG, >> about allowing devices on the network not being prepared to be on the >> global Internet use ULAs. that way >> we can avoid firewalls on the network borders, and still protect the >> unprepared... ;-) > Yes the problem is that source address selection seems to be a trouble > on clients. I just had users / tester complain yesterday about devices > using ULA instead of the 200X: source addresses breaking connectivity > when both are announced so now I had to implement a hack that sets > the preferred time of the ULA to 0 when there are prefixes with global > reachability. we need to get the hosts fixed for this. right now, given the state of affairs my recommendation would be not not = enable ULAs by default. > Similarly I see NPT only as a way to work around client issues > - especially when having multi-homing / redundant uplinks - > and not as a default way of doing things. I'd really like us to avoid that. it is going to be so hard to get NPT = out of the network again. it also forces applications to continue with STUN/TURN and all that = stuff to discover global addresses that can be used for referrals. please let us keep the end to end = properties of IPv6 intact. cheers, Ole