[00:13] *** hiro_dSn_ has joined #arpnetworks [00:15] *** hiro_dSn has quit IRC (Ping timeout: 265 seconds) [00:15] *** nukeAFK is now known as nuke- [01:05] *** LT has joined #arpnetworks [04:18] *** nesta has joined #arpnetworks [04:43] *** nesta has quit IRC (Remote host closed the connection) [04:45] jeeze, what is google doing? [04:46] ? [04:47] now i can change the bg image? google is becoming lame [04:47] ugh [04:48] stupid [04:48] yeah [04:48] keep it simple, stupid :) [04:49] yup [04:56] oh man [04:56] i see what you mean [04:57] what the hell are they thinking, it's awful [04:57] if you switch javascript off for google you don't get the background [05:42] it's so Bing'y [05:42] apparently it's only for 24 hours [05:43] then you willhave hte option of keeping it, or disabling it [05:43] stupid google [05:46] http://lifehacker.com/5559961/turn-off-googlecoms-24+hour-background-image [05:47] the embossed stuff still looks stupid :/ [06:06] *** ziyourenxiang has joined #arpnetworks [06:09] *** fink has joined #arpnetworks [06:20] *** fink has quit IRC (Quit: fink) [07:04] up_the_irons: first thing I did after getting your email is login to my main box and make sure it's all still there :) [07:04] up_the_irons: we're good. thanks. [07:52] *** ziyourenxiang has quit IRC (Quit: ziyourenxiang) [08:00] Wraithan: ping re: arch installation [08:03] n/m [08:53] cedwards: ? [08:56] *** woremacx has quit IRC (Ping timeout: 265 seconds) [08:57] *** woremacx has joined #arpnetworks [08:58] Wraithan: couldn't figure out the grub entry for vda devices, but I got it. [09:22] *** LT has quit IRC (Quit: Leaving) [09:26] oh [09:26] yeah [09:58] *** toddf has quit IRC (Ping timeout: 260 seconds) [10:07] *** Yamazaki-kun has quit IRC (Ping timeout: 260 seconds) [10:08] *** toddf has joined #arpnetworks [10:08] *** ChanServ sets mode: +o toddf [10:14] *** Yamazaki-kun has joined #arpnetworks [10:39] *** schmir has joined #arpnetworks [10:41] http://www.youtube.com/watch?v=QAue4hnH8-A [10:43] arp networks not listed on http://www.fix6.net/ipv6-webhosting/ [10:58] I swear Kubuntu is going to drive me to start using Gnome... [10:59] jdoe: so don't use Kubuntu. [10:59] jdoe: the best KDE I've found is http://chakra-project.org [11:06] cedwards:I'm basically screwed by my own mistrust. [11:06] I don't want to screw around with minor distros and I don't trust arch. [11:06] jdoe: then I guess you're screwed. [11:06] yep. [11:07] why is it that you don't trust arch? [11:07] so my options are basically centos, fedora, *buntu and debian. [11:07] the first two are polished but upgrading them sucks, the kubuntu sucks, and debian is stale :/ [11:08] *** mdg has joined #arpnetworks [11:09] Hi, I currently have an OpenBSD VPS with you guys, but I would like to switch it to Arch Linux, is this possible ? [11:09] mdg: heh. I just did that one one of my machines. [11:10] mdg: it's possible. you'll need to submit a support@ request, and there is some manual config to be done during install. [11:10] cedwards: were you doing the $20/month (and did your pricing change?) [11:11] mdg: I am doing the $20 (I have two machines). No price change, just a support request for him to reprovision is all. [11:11] cedwards: I might give fedora a shot. [11:11] cedwards: awesome, thanks [11:12] mdg: the reprovisioning will require your current system be destroyed, so make sure you've got what you need. [11:12] mdg: ..and I'll document on the wiki the manual tweaks required to get an Arch machine running properly. [11:14] sounds good [11:22] cedwards: sorry, distracted before. My beef with arch is that I'm not sure how big the maintainer community is. [11:23] for all I know it's just some dude like Slackware. [11:26] jdoe: it seems to be pretty big. I've actually been helping build and test packages for chakra-project, and our -devel channel has been pretty busy. [11:26] everything goes through -testing before it goes public. [11:27] and what I've been doing is compiling the entire repository in a chroot, helping ensure each package is compatible with the rest. [11:35] jdoe, its a good size for the size of the community. There are TUs which aid in package maintenance as well [11:37] mdg: irc is very active, although it seems to be 12yr olds. [11:43] yeah heh [11:45] i used to spend a lot of time in the arch channel it has changed a ton from when i started with arch [11:46] never tried arch [11:46] i've mostly been on debian in my linux experience [11:46] i tend to break it :/ [11:47] i went from slack for 2 years to fedora for 3 weeks slack for a few more years then arch for the last 2 or 3 years [11:48] * mdg recalls seeing Wraithan in -offtopic [11:48] The fun thing about Arch is that the community doesnt take itself too seriously [11:48] mdg: i am the founder of the -ot renegade channel [11:50] and everything is so stinking simple. it's great [11:50] renegade ? [11:54] plol [11:54] Well, we had a issue with the ops in #archlinux-offtopic so we started another channel that everyone was an op in [11:55] then that blew up because the founder of that one went all nazi too [11:55] who was the founder of that one ? [11:55] so I started ##lessthanthree and that's our new home [11:55] daedhel [11:55] heh [11:58] how long have you been an archer mdg / [11:58] ? [12:01] I remember when #archlinux was a channel that if the answer was on the wiki or man page, we used to give kids RTFM and leave them at that, now it is all about the hand holding #ubuntu-like stuff with ops banning for stupid cra[ [12:05] Wraithan: ~ 3 years [12:06] I see that a lot too, ubuntu users for some reason decide to try arch and then get mad in irc because it doesnt work like ubuntu did [12:07] but the archwiki, you cant beat it [12:29] I use the archwiki when troubleshooting stuff on the gentoo and ubuntu servers at work [12:47] hi guys! [12:51] *** schmir has quit IRC (Ping timeout: 240 seconds) [13:05] HELLLOO [13:35] oh hey [13:54] mdg: TU = trusted user or similar? Why should I trust them? :P [14:00] jdoe: because the developers do [14:01] jdoe: why do you trust the developers of your distro? [14:04] lessthanthree is a great name :) [14:04] http://lessthanthreesoftware.com [14:04] That's my blog [14:04] lol [14:07] nice :) [14:08] love the last post [14:08] had a very similar experience [14:09] people think websites take like two seconds :( [14:10] http://www.teamfortress.com/macupdate/ -- for all you macf-- er users :) [14:26] Wraithan: TU implies some forum rat, debian has ridiculous bureaucracy, redhat/suse have actual companies overseeing that. [14:26] so yeah, there's a difference. [14:27] redhat/suse are crap [14:27] +1 [14:27] TU is more than forum rat, these are people who have maintained packages in the AUR which is a user based repository for packages [14:27] i remember using redhat about 12 years ago [14:27] it was 'ok' then [14:28] in fact, i think my first linux experience was suse [14:28] but then i was shown freebsd, and i must admit, i've absolutely *never* looked back [14:28] sometimes they become a TU because they are taking one of the AUR packages to a official repo, then they are moved into taking care of more projects [14:29] probably helps that i was shown by the chap who used to be the official freebsd documentation editor [14:29] redhat isn't crap for what it is. [14:29] jdoe: it hurts the linux world. [14:29] having a stable platform for production use? how terrible. [14:30] have a stable platform that encourages people to not move forward and therefor keep progress in check if folks want to support 'enterprise' as well [14:30] yeah, doesn't sound bad at all. [14:31] python 2.3 and 2.4 should be dead. [14:31] 2.7 is coming out next month [14:32] heh [14:32] see, here's the thing. [14:32] suppose I have an app written for python2.3 (and I do indeed have just such an app, although not on redhat) [14:33] my options are to fix the app for whatever version redhat/debian/whoever decides to ship. [14:34] ... or I can have that platform supported and not waste the time and effort. [14:34] that's a no-brainer. [14:34] waste? [14:34] yes, waste. [14:34] There is a reason the python language has progressed in ways that aren't backwards compatible [14:35] yes, but none of that invalidates the way things were previously done. [14:35] it worked before, and it will continue to work for the foreseeable future. [14:35] so yes, it's a waste for us to fix the app. [14:35] maybe you should have kept up with python [14:35] it isn't bad porting from 2.3 to 2.4 [14:35] or 2.4 or 2.5 [14:36] right, but it takes more than zero effort, right? [14:36] and the benefits from my POV are negligible. Things might perform slightly better, but my current setup is never going to perform worse. [14:37] But the additional effort required because you are using some ANCIENT verison of python and can't run 2.6 because there are libaries you can't update because your system is so old [14:37] what effort? [14:37] it's supported for years. [14:38] rhel does 7 years of support for major versions. [14:38] additional effort because only old libraries which are also unsupported now [14:38] so you are rebuilding everything [14:40] true, but 7 years is a long time, after that long I probably would be anyway. [14:40] but you are chosing to ignore that cost [14:40] and the difference is it's on my timeline, not because some distro EOL'd a version after a year. [14:40] heh, yeah sure [14:41] to each their own, but I never thought I'd hear someone call stability a *failing* of linux.. [14:41] you and every other programmer who has said, we have plenty of time, we can just update it later [14:41] funny thing is the cost of updating grows over time [14:42] I'm not a programmer, I'm a sysadmin. [14:42] Ah [14:42] I've never met a programmer who wouldn't jump at the chance to upgrade to python 3.14 [14:42] Not quite a bad but almost [14:42] * Wraithan is a programmer [14:42] for me, show me a tangible, immediate benefit or gtfo ;) [14:43] well no, not immediate. [14:43] I'm low on blood sugar and rambling now. I need food. [14:44] :) [14:44] i still haven't got stuck in to python [14:45] i bought the book [14:45] *books [14:45] now they are out of date [14:45] :( [14:45] what version do they teach? [14:46] sec [14:47] 2.0 hehe [14:47] i'm sure i wouldn't have any trouble learning the new stuff though [14:47] 2.0? [14:47] that's what it says [14:48] o'reilly books, from at least, hmm, four years ago? [14:48] book is 10 years old? [14:48] maybe more than four years [14:48] 'covers python 2' is what is says :/ [14:48] oh [14:48] ok [14:48] probably 2.4 [14:48] i find that i need a project to learn a new language [14:48] never really found a project [14:49] i was going to write a radius server in python but 'hmmmmmmm' [14:49] maybe with twisted or sth [14:49] diesel > twisted [14:49] lol [14:49] meh [14:49] don't really know hehe [14:49] twisted is not like writing python it is like writing twisted [14:50] i guess i'd want a new 'thread' for every inbound UDP packet [14:50] but as i say, never had to actually do anything with python so :) [14:51] i wrote a radius client in php a few years ago, that was fun [14:51] that was before i ended up writing a usenet binary grabber in php with rate limiting [14:51] fun projects, now i hate php [14:54] wth does my /etc/event.d/ttyS0 work in Jaunty but not Lucid [15:01] *** Jestre has quit IRC (Read error: Connection reset by peer) [15:02] *** Jestre has joined #arpnetworks [15:11] dunno [15:11] I hate writing for upstart though. [15:12] i don't really get why it matters that a box takes a little while to start [15:12] hence i don't really get the point of upstart [15:13] well it makes init dependencies more sane. [15:13] and it gives you some easier triggers than what init allowed. [15:13] ... but users don't care about that so they boast about how instead of taking 15 seconds to boot now it takes 14. [15:14] * Wraithan uses a BSD style init with linux [15:14] bsd style makes more sense to me [15:14] i can't even begin to understand runlevels, especially in the context of 'today' [15:14] and tbh i don't really care how long a restart takes [15:15] but that's probably because we have redundant everything [15:15] even on a lone machine I don't care [15:15] same, tbh [15:15] init is the fastest part of the boot anyway [15:16] I've got to wait minutes for the controllers to init. [15:16] yup [15:16] dell servers tend to take even longer than that tbh [15:17] been a while since I had to deal with one. [15:18] tbh, when you look at how long it takes to restart something like a cisco 6500 with something like a sup720 [15:18] everything comes into perspective :) [15:18] 10+ minute downtime right there [15:22] indeed. [15:51] new IPv6 policy for new VPS setups: [15:51] " A /48 IPv6 block has been allocated to your site as recommended by RFC 3177 and RFC 5375. [15:51] However, only the first /64 is directly connected (assigned) to your VLAN. [15:52] Should you require use of the entire /48 at this time, we will route it to you over a link-local address. [15:52] Please email support@arpnetworks.com to set this up. " [15:52] this will appear in IP Block detail in the Portal for new setups [15:52] I think it is a saner default [15:52] makes perfect sense :) [15:52] and the info appears a little different, so as to make this clear [15:52] putting a /48 on the VLAN always made me uncomfortable [15:52] toddf will like this change ;) [15:53] hehehehe :) [15:53] YAYAYAYAYAYAYAYAYAYAYAYA [15:53] the next sane default would be a link local address for the gateway [15:55] LOL [15:55] :D [15:55] what is the effect of this change? [15:55] I'm not following [15:56] toddf: I'll have to wrap my head around that more. What I don't want is for a 2+ VPS setup to require one of the VPS's to be a gateway, unless this is explicitly requested by the customer [15:56] that makes sense, up_the_irons [15:56] ipv6 is a confusing beast [15:56] I mean, what can you do with the new setup that you can't do with the old one [15:56] coudln't I always say that my em0 was /64 [15:56] and then create other nets near it? [15:57] RandalSchwartz: nope [15:57] RandalSchwartz: b/c the /48 was on the wire [15:57] the whole /48 was routed to your VPS previously, no? [15:57] https://twitter.com/IPv4Countdown [15:57] RandalSchwartz: the /48 would have to be routed to you, over say a link-local address, for you to subnet it further [15:58] RandalSchwartz: exactly same like IPv4. If I put a /24 on the VLAN, you can't subnet it. But if I route the /24 over a /30 to you, then you can subnet further. This new policy will allow this to happen in a more organic way. People who don't need it will accept the sane default, and people that need it (very few), can request it [15:58] well, wouldn't my em0 act as a proxy arp them? [15:58] you'd route all of the /48 to my em0, then I could further route it [15:58] RandalSchwartz: yes, if you wanted that, sure [15:59] RandalSchwartz: not sure wrt proxy arp [15:59] yeah - so I don't see what the change buys me yet [15:59] as long as I'm not putting two pieces of the /48 in entirely disjoint places [15:59] but I can't, because the global routing table can't handle that [15:59] up_the_irons: the difference between global and link local for the default gateway is not huge, but if a customer wanted a different /64 routed to the VPS, no change for default gateway [15:59] RandalSchwartz: you shouldn't. with only a couple VPS's, there is really no need to further subnet a /48 [16:00] RandalSchwartz: unless you want to do some tunnel's and have individual /64's for the tunnels [16:00] randalschwartz: this isn't about arp, v6 doesn't have arp! [16:00] how does it map an address to ether then? [16:00] ndp [16:00] bob^^: yeah, previously, the whole /48 was assigned to the VLAN, which worked but sets a bad example; it shouldn't really be done that way in retrospect [16:00] v6 does multicast [16:00] yeah, indeed [16:01] ping6 -n -w ff02::1%em0 [16:01] i like the new default :) [16:01] makes sense :) [16:01] that'll get you all kame based systems on the wire, unless firewalled [16:01] ping6 -n -w ff02::2%em0 [16:01] toddf: roger [16:01] that'll get you all sysctl net.inet6.ip6.forwarding=1 kame based systems on the wire, unless firewalled (read: all your routers) [16:02] the ff02::/8 is a special multicast subnet .. compare with 224.0.0.0 on ipv4, but always present in v6 [16:02] it permits link local discover of addresses, both global and link local [16:02] yeah [16:03] so if I want my laptop to have a piece of my v6 with a 6over4 tunnel of some kind to my apr box, I can't do that right now, because em0 will answer for all /48 ? [16:03] so a combo of ff02::/8 multicast and fe80::/8 link-local addresses come into play to discover local addresses [16:03] precisely [16:03] ahh. I thought I could do that before [16:03] so I'll want mine changed. :) [16:03] oh cool [16:03] if you want to route a /64 to your laptop you'll need a /64 routed to your vps and then re-route that /64 to your laptop over a tunnel [16:03] i hadn't thought of that [16:03] what the new default permits [16:04] is one /64 for the link local of your vps [16:04] then the rest of the 65535 /64's just routed to your vps [16:04] so you can then do with them what you want, including assign them to lo1 lo2 lo3 or whatever [16:04] yeah, ok, sign me up! [16:04] wow, i just did "ping6 -n -w ff02::1%em0" on a test VPS [16:04] or .. if you enable forwarding for v6, you can setup tunnels to remote systems to utilize the address space [16:04] interesting! [16:04] if I change my /48 to a /64 right now, will it break anythin? [16:05] in anticipation of the change? [16:05] the -w is the `kame specific' option, w/out it even linux and cisco respond [16:05] it sees the router and the console server. i wonder why the console server is in there... [16:05] randalschwartz: changing to a /64 will not break if your v6 addresses lie within that /64 including your upstream gateway [16:05] now if your upstream gateway were the link local of the upstream router, the 'including your upstream gateway' goes away in the above sentence [16:05] oh, same vlan, f'in duh [16:05] yeah - that's true so far [16:06] the %em0 means 'this ethernet segment attached to em0' [16:06] and if anyone who has an existing VPS wants to change to the new default, just let me know; it's a pretty easy change [16:06] randalschwartz: because bsd systems assign networks to interfaces when you assign addresses, just changing the prefix on the interface may not change your routing table, it may be a maintnence reboot to make sure all tendrils are in proper order [16:07] so what interface does the remainder of the /48 come in on? [16:07] randalschwartz: its routed to you [16:07] I'd take v6 down and up [16:07] as in, it also comes in via em0? [16:07] think if you were on a subnet with 10.0.0.1 as router and 10.0.0.2 as your vps and 10.0.0.0/24 for the network .. and someone routed you 10.0.0.0/16 to your 10.0.0.2 vps .. same deal [16:08] ahh, but I can say 10.0.0.3/2 goes over there ==> [16:08] just rinse and recycle with v6 subnets of /64 and /48 instead of /24 and /16 [16:08] since I'm now only 1,2 [16:08] well, 10.0.0.0/24 ought to be on the native wire [16:08] 10.0.1.0/24 however you can point elsewhere since its routed to you and you can (and maybe even should) add a reject route for the larger block and route only the speicifc ones that are accessable [16:09] ahh. I mean 10.0.1/24 is "over there" [16:09] right [16:09] yeah - that's what I was getting at [16:09] upstream router would send any of 10/16 to me [16:09] but only 10/24 is considered "me" [16:09] by "me" [16:09] and the specific link local of 10.0.0.0/24 over-rides the route of the 10/16 [16:09] yeah, that's how I thought it was working now anyway [16:10] what we had for a previous default is 10/16 on the wire, period [16:10] equivalent mind you [16:10] but if I assigned /24 to em0, and 10.0.1/24 to lo1 [16:10] wouldn't it just do the right thing? [16:10] I mean, why does upstream care? [16:10] previously, no [16:10] the wire would do arp requests for 10.0.1.X thinking its on the local link [16:11] ahh... [16:11] it's starting to sink in [16:11] ok yes, I want this change. :) [16:11] what a router considers on the local link it won't magically `route' to a box on the link, unless that box does proxy arp, in which case its faking things and doing fudgery I'd care not to endorse ;-) [16:11] not sure if v6 even has 'proxy ndp' [16:12] while the term 'link local' originates from v6, you get the same concepts in v4 `within the subnet on the wire' [16:12] email to support done. :) [16:12] toddf: it does indeed do proxy ndp, which was required on some tunnels for customers when I put the whole /48 on the wire [16:12] up_the_irons: I hereby put this whole discourse under public domain, at least my part, do with it what you will, for the furtherance of `proper(tm)' networking *grin* [16:12] as long as I'm not using any address above the /64, it doesn't matter how I'm set up, right? [16:13] at least so I have to worry about a transition [16:13] toddf: cool! [16:13] randalschwarts: technically no, but a mismatch in prefixlen from router to vps cannot be a thing to expect no problems from ever ;-) [16:13] Right. I'll fix it as soon as I hear I've been changed [16:14] it `happens' to work, just as if the router thought 10.2.3.0/24 were on the link and the client thought 10.2.0.0/16 were on the link and the client happened to use 10.2.3.2 and hit the router at 10.2.3.1, it would magically work, but obviously there is potential for `fun' down the road [16:14] in theory then, I could assign each jail its own /64 [16:15] and nat the ipv4, right? [16:15] (I once had a client where the router was outside the local subnet, and windows somehow worked fine, for bsd to exist I had to widen the subnet mask considerably...) [16:15] [arin-announce] IANA IPv4 Free Pool is Now at 6.25% [16:15] wow [16:15] yes you could [16:15] it was 10% 6 months ago! [16:15] "imminent collision... sound the klaxons" [16:15] "followed shortly by the failtrombone" [16:17] "network_ipv6 stop" doesn't do what I thought [16:19] but "ifconfig em0 inet6 dead:beef:babe::/64 does [16:19] fixed up the routing too, looks like [16:19] I don't see any /48's in there now [16:25] toddf: if I route a /48 to a link-local, is there any way to get around the fact one must choose one vps as the gateway, and then ipv6 forward to all others (makes that vps more of a single point of failure) [16:27] initiall you'll have customers with a single vps [16:27] you'll have a /64 on the wire [16:27] and your router is the default upstream [16:27] well yes, that's the new default now [16:27] if they get more vps's they can choose to put them all in that one /64 [16:27] the rest of the /48 can be routed as a group to one vps or split up amongst several vps's [16:27] right right, but should they want the /48 routed... then what? [16:27] presuming they're all on the same host box [16:28] if they're wanting failover they can put the link local address into a carp group between vps's [16:28] roger [16:28] carp diem! [16:28] fish of the day! [16:28] but how can the /48 be split up amongst several vps's if it is routed? I can only pick one destination of the route [16:29] you can split the /48 into 65535 /64's if they really want 65535 individual vps's with individual /64's [16:29] not that your routing table would be happy but it could be done theoretically [16:29] toddf: right, that's just the "manual" (email support) way of doing it [16:30] if you wanted an automated way of splitting it up, ospf comes to mind as superior to rip6 [16:30] toddf: if they want the whole /48 routed and want to be self service, then they have to accept that one vps, or some device, will be a gateway for them [16:30] i take it [16:30] I may use rip6 for my upstream tunnel to iijlabs which wrote kame, but thats the only place I've used either [16:31] one mac address on the link must respond as a router for the /48 yes [16:31] roger, that's all i wanted to clarify [16:31] they could have multiple vps's responding to that one mac address per carp(8) or other similar technology [16:31] note that 'fe80::X' addresses can also be aliased [16:32] $ ifconfig vlan8 [16:32] vlan8: flags=8943 mtu 1500 lladdr 00:0c:76:55:82:1b description: wifi-default priority: 0 vlan: 8 priority: 0 parent interface: trunk0 groups: vlan physical internal inet6 fe80::20c:76ff:fe55:821b%vlan8 prefixlen 64 scopeid 0xd inet6 fe80::2%vlan8 prefixlen 64 scopeid 0xd [16:32] blah stupid irssi [16:32] $ ifconfig vlan8 [16:32] vlan8: flags=8943 mtu 1500 [16:32] lladdr 00:0c:76:55:82:1b [16:32] description: wifi-default [16:32] inet6 fe80::20c:76ff:fe55:821b%vlan8 prefixlen 64 scopeid 0xd [16:32] inet6 fe80::2%vlan8 prefixlen 64 scopeid 0xd [16:32] $ ifconfig carp8 [16:32] inet6 fe80::200:5eff:fe00:108%carp8 prefixlen 64 scopeid 0x15 [16:32] inet6 fe80::1%carp8 prefixlen 64 scopeid 0x15 [16:33] inet6 2001:240:58a:2::1 prefixlen 64 [16:33] $ ps ax | grep rtadvd [16:33] 21080 ?? Is 0:10.62 rtadvd carp3 carp6 carp8 carp13 carp14 [16:33] .. on a client system: [16:33] $ ping6 -n -w ff02::1%rum0 [16:33] PING6(72=40+8+24 bytes) fe80::69%rum0 --> ff02::1%rum0 [16:33] 40 bytes from fe80::69%rum0: knetbook.fries.net. [16:33] 37 bytes from fe80::1%rum0: carp1.fries.net. [16:33] 37 bytes from fe80::2%rum0: carp1.fries.net. [16:34] $ netstat -nr -f inet6 | grep def [16:34] default fe80::1%rum0 UG 11 10546019 - 4 rum0 [16:34] toddf - so after the change to the link-local /48, what's my outbound default route going to look like? [16:34] what I just showed you is a carp'ed v6 gateway responding on multiple link local addresses, and the client having auto-discovered the carp'ed link local for default gateway [16:34] my em0 is now /64, right? [16:34] randalschwartz: depends on if I talk up_the_irons into link local or global .. ;-) [16:35] which would be better? [16:35] I'm sure he's listening. :) [16:35] randalschwartz: in reality, anything thats on the link and subnets you have configured that the router responds to [16:35] the `path with most options' is link local, the `path that mimics old v4 behavior better' is global [16:35] my existing ::1 for example? [16:35]