[Bloat] Testing Queue models

[Dave Taht]

On Wed, Feb 1, 2012 at 9:08 PM, Justin McCann <jneilm at gmail.com> wrote:
> On Wed, Feb 1, 2012 at 12:12 PM, Dave Taht <dave.taht at gmail.com> 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....

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net