From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-gx0-f171.google.com (mail-gx0-f171.google.com [209.85.161.171]) (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 04735200624; Wed, 1 Feb 2012 12:38:32 -0800 (PST) Received: by ggnu1 with SMTP id u1so1533308ggn.16 for ; Wed, 01 Feb 2012 12:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rMPTVn3qnmy3wPFfJeEVdcr4PuCwpCmlhopXixtJXbo=; b=U/V00tHMIXO6YSnpx4vxQuEgHIOy38vTPm5QaVirfqoEagV6PBajRPFscvJEkZBdj9 MAp1YYhdWju1nOolWWU1VIRIa4BPv+tNGnGAvzHOIlgvETvc1c4MvlYjreI/iDd/g/6U cwfEz9HF9XGSEwdVdr13Wtdl8ih8OBRFirPRc= MIME-Version: 1.0 Received: by 10.50.189.137 with SMTP id gi9mr136042igc.29.1328128710802; Wed, 01 Feb 2012 12:38:30 -0800 (PST) Received: by 10.231.7.21 with HTTP; Wed, 1 Feb 2012 12:38:30 -0800 (PST) In-Reply-To: References: Date: Wed, 1 Feb 2012 21:38:30 +0100 Message-ID: From: Dave Taht To: Justin McCann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel@lists.bufferbloat.net, bloat Subject: Re: [Bloat] Testing Queue models X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 20:38:33 -0000 On Wed, Feb 1, 2012 at 9:08 PM, Justin McCann wrote: > On Wed, Feb 1, 2012 at 12:12 PM, Dave Taht wrote: >>... >> Even getting 1/d is hard because the filters can only use IP and IPv6 >> addresses, so a device issuing traffic on both ipv4 and ipv6 can get >> twice what it deserves in terms of bandwidth, or more if it has >> multiple ipv6 addresses. >> >> My preferred solution to this (and part of the wireless problem) is to >> sort things out by source mac address. How to do that, remains a >> mystery. The way I'm leaning is to invent some sort of "src mac-to-id" >> filter that is global router-wide. > > A friend and I were discussing last week how each device on an IPv6 > network can and will have multiple addresses, so classifying becomes a > bit trickier. But I guess most devices are supposed to have one (ha!) > /64, so you can ignore the lower-order bits? I assume that sort of > IPv6 alias resolution is a solved problem already...? I've been thinking about this kind of hard because I was irked and surprised by dibbler-pd's default behavior. When it exits, it withdraws the ip addresses it gets... and there seems to be an explicit assumption that there are no other ipv6 addresses on the network. Now, personally, I kind of expect an IPv6 network to KEEP WORKING when disconnected from the internet. In fact, I expect it to come up, working, when disconnected from the internet, at the same time ipv4 does, and stay working, regardless of whether there is a gateway to the outside world. some people actually still like, to um, print, or have a file server, etc. What appears to be the correct way to do ipv6 in the home, and maybe the general case is to apply RFC4193, which I sat down to implement yesterday. These were my notes regarding the proposed unique local address generation scheme in opening a new router and getting up on the net. 1) Obtain the current time of day in 64-bit NTP format [NTP]. I'm not on the internet yet, and time will either be the epoch, or the build date. And ntp may or may not be working yet. 2) Obtain an EUI-64 identifier from the system running this Great. I note that fairly often macs are twiddled with on wireless and the local bit is often set nowadays too... 3) Concatenate the time of day with the system-specific identifier in order to create a key. The rfc doesn't specify case, or binary, or ascii, or how you concat 4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1]; the resulting value is 160 bits. And the randomness from the time is non-existent. 5) Use the least significant 40 bits as the Global ID. 6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global ID to create a Local IPv6 address prefix. So great, we need, in order to generate that first address: ntp openssh (for sha), or sha1sum Which is all encapsulated in an 88 line shell script that I just pulled off the net. While I got that working, I was not including the openssl or sha1sum utility required for it, which eats 256k on flash, and isn't needed for anything else... and most embedded distros have no means of getting the 64 bit ntp value out of their clock, lacking ntp. Then the RFC skips the all-important step of: 7) Update DNS to suit as out of scope, regardless of the fact that there is no way to get this new address to the user or device, otherwise. So having an random arbitrary and likely-to-be-unique address is handy... fdfd:7c1a:c378::/48 (which takes over a second to generate on cerowrt) But there is no way to use that sanely until you have dns, and your provider isn't going to do a ula for you so you need your own dns server, and that address inserted into your dns 8) then you need to break that up onto a sane mapping for the interfaces you have. 8a) firewall off your guest and secure networks 9) Make sure you don't route these out your gateway, 10) supply them to clients via dhcpv6 or radvd. And get names for those into dns, somehow. 11) Then, assuming you get real, static ipv6 addresses, deprecate the ulas entirely from your network. If however, you don't own your ipv6 addresses, you'll want something stable, so you keep them, leading to at least two ipv6 addresses per device... 12) as best as I can tell gai.conf doesn't prioritize for ula addrs by default, so if you remove the addresses from your network dynamically, long running tcp sessions will fail.... and did I mention the firewalling problem already? /me takes long sip of kool-aid... There's probably another 30 steps here.... --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net