From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 42E0D21F12A for ; Mon, 10 Dec 2012 03:40:53 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id k13so10605825iea.22 for ; Mon, 10 Dec 2012 03:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=aohELAG0DpV9FbRiT4sW2kUcAt8vj8usg5NkcqSDanY=; b=VMW3DPUThM7zeGbgPnQa10StOyvg6cciZ7aeKYAP5IyIBs7GnBe2htWoCcwUfdlzNl BthoM2RApfNFnOpR2RNqUWbLLEUhyon3b9L89oENHU1gbZdVdU5O+wOXhjLM+6NRspe+ KjNY5lRcw0fzZu5rhWHFLYvZAETfhutkHJTrCtAtwuYSBxocCtlC6EodUWdAd4KbCxN3 2NNhaGgCjhu/c8qH35/mX5HtxDuDrVkHFNrCJtwQIA2grksQcotxwoBs8UJbRGx7AlNk epWNERVAlnoK6MiKIXSEHjw8gCyoP47iwq5gK2SYAvu8Mcm6w9Re+V2FVGcZI0+wujE0 GtVw== MIME-Version: 1.0 Received: by 10.50.150.144 with SMTP id ui16mr6265480igb.68.1355139652622; Mon, 10 Dec 2012 03:40:52 -0800 (PST) Received: by 10.64.135.39 with HTTP; Mon, 10 Dec 2012 03:40:52 -0800 (PST) In-Reply-To: <50C5C705.3060108@openwrt.org> References: <50C5C705.3060108@openwrt.org> Date: Mon, 10 Dec 2012 12:40:52 +0100 Message-ID: From: Dave Taht To: Steven Barth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Mon, 10 Dec 2012 11:40:53 -0000 On Mon, Dec 10, 2012 at 12:27 PM, Steven Barth wrote: > On 10.12.2012 10:15, Dave Taht wrote: >>> >>> * Prefixes are automatically split up and distributed over >>> downstream-interfaces OR by choice mapped to an ULA-address (NPT66). >> >> >> Hmm. The homenet folk have a prefix assignment and router discovery >> process defined in their PD over ospf (somewhat crazy) >> implementation... >> >> My expectation here is that ISPs are going to be parsimonious in >> handing out anything bigger than a /64, certainly anything bigger than >> a /56 is going to be scarce. So I'd hope that address assignment using >> NPT66 would start with the bottom addresses and work up. > > > cerowrt would run into problems if the ISPs would only assign a single /6= 4. > Even NPT would not help here as two distinct ULA /64 could not be mapped = to > the same public /64 without the possibility of collisions. So it might be > necessary to relay between the downstream interfaces in this case so that > they share a /64 or did you have something else in mind? The current lack of anything greater than a /64 from places like free and comcast... is why I use ahcp for everything, myself. /128s. I also gain the ability to move transparently from wired to wireless and back again without losing my 20 ssh connections or the movie I'm playing. Not that wires matter anymore. Not being able to get anything greater than a single delegated /64 has been quite maddening, to date. I'm glad to know that free actually distributes a /60 and that comcast has plans to do /60s or better. and that the principal barrier to wider distribution of more prefixes is mostly due to flaws in the dhcp-pd clients. > > However I guess and from what I have seen most ISP will probably assign a > /56 or at least a /60. For OpenWrt a /64 would not so problematic as ther= e > is - by default - only 1 (bridged) lan-interface so a single /64 is > sufficient for most users. Well, I abhor bridging 2.4 and 5 ghz wireless together, and then there is the ever more popular concept of a "guest" network... > This is how the prefix distribution works either for the ULA or the publi= c > prefixes. I've implemented this straight forward not looking at any > specification as the local prefix distribution should not be mandated imo= by > any RFC. Heh. > > * For ULA fd00::/48, the first /64 would be fd00::/64, the 2nd > fd00:0:0:1::/64 etc. It would be my hope to not standardize on fd00::whatever, but to actually generate random ones. Doing vpns between your standardized 192.168.0.1 addresses is painful.... and with better naming, the pain of having to remember these large numbers goes away (a bit.) > * Padding (unused adress-space) is added if the alignment cannot be > satisfied (e.g. one interface wants a /64, the second a /62, then there w= ill > be a padding or 1 /64 and 1 /63 in between). > * If a downstream-interface goes down, its assigned prefix is preserved i= n > case it later comes up again. > * Assignments for a public prefixes are forgotten once the prefix is remo= ved > (e.g. wan goes down). My understanding is that public prefixes can be kept until the wan comes up= . That said, I'd argue in favor of expiring them as fast as possible if ula's already exist. > In the current implementation the NPT will map the public prefix to the > lower part of the ULA, meaning a public /56-prefix will be mapped onto > fd00::/56 if the ULA is fd00::/48 and everything outside this /56 would n= ot > be mapped so care has to be taken. This is a bit unpredictable - I know - > but in the end we cannot know what size the public prefix from the ISP wi= ll > be and I guess if there are only a few /64-downstream interfaces it is > unlikely to clash for a majority of users. > > > >> >> Somewhat related to that, is the concept of actually USING ipv6 for a >> few things that it's good at. For example, a much greater randomized >> port space can be gained if the dns server is the only daemon >> listening on a dedicated ipv6 address (like a ::3) > > > I'm currently wondering if it would make sense to implement a randomizati= on > strategy in case we have e.g. a /56 prefix and only want to assign one or > two /64 so that the /64 would not always be ...1::/64 and 2::/64 but it > would be a bit complicated with the dynamic prefix assignment of > downstream-interfaces and especially when it comes to ULA and us not know= ing > before-hand what length the public prefix will be. I think randomizing would help against attacks, yes. Somewhat related, you could do something SLAAC-like on the inner interface's /64. In prior versions of linux using a dhcp-like address assignment strategy hashed badly. (I note that I'm more of a fan of slaac than dhcpv6) --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html