<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
***: hiro_dSn has quit IRC (Ping timeout: 265 seconds)
<br> nukeAFK is now known as nuke-
<br> LT has joined #arpnetworks
<br> nesta has joined #arpnetworks
<br> nesta has quit IRC (Remote host closed the connection)
infrared: jeeze, what is google doing?
bob^^: ?
infrared: now i can change the bg image? google is becoming lame
bob^^: ugh
infrared: stupid
bob^^: yeah
<br> keep it simple, stupid :)
infrared: yup
bob^^: oh man
<br> i see what you mean
<br> what the hell are they thinking, it's awful
LT: if you switch javascript off for google you don't get the background
up_the_irons: it's so Bing'y
bob^^: apparently it's only for 24 hours
<br> then you willhave hte option of keeping it, or disabling it
<br> stupid google
cedwards: http://lifehacker.com/5559961/turn-off-googlecoms-24+hour-background-image
bob^^: the embossed stuff still looks stupid :/
***: ziyourenxiang has joined #arpnetworks
<br> fink has joined #arpnetworks
<br> fink has quit IRC (Quit: fink)
cedwards: <u>up_the_irons</u>: first thing I did after getting your email is login to my main box and make sure it's all still there :)
<br> <u>up_the_irons</u>: we're good. thanks.
***: ziyourenxiang has quit IRC (Quit: ziyourenxiang)
cedwards: <u>Wraithan</u>: ping re: arch installation
<br> n/m
Wraithan: <u>cedwards</u>: ?
***: woremacx has quit IRC (Ping timeout: 265 seconds)
<br> woremacx has joined #arpnetworks
cedwards: <u>Wraithan</u>: couldn't figure out the grub entry for vda devices, but I got it.
***: LT has quit IRC (Quit: Leaving)
Wraithan: oh
<br> yeah
***: toddf has quit IRC (Ping timeout: 260 seconds)
<br> Yamazaki-kun has quit IRC (Ping timeout: 260 seconds)
<br> toddf has joined #arpnetworks
<br> ChanServ sets mode: +o toddf
<br> Yamazaki-kun has joined #arpnetworks
<br> schmir has joined #arpnetworks
Wraithan: http://www.youtube.com/watch?v=QAue4hnH8-A
RandalSchwartz: arp networks not listed on http://www.fix6.net/ipv6-webhosting/
jdoe: I swear Kubuntu is going to drive me to start using Gnome...
cedwards: <u>jdoe</u>: so don't use Kubuntu.
<br> <u>jdoe</u>: the best KDE I've found is http://chakra-project.org
jdoe: cedwards:I'm basically screwed by my own mistrust.
<br> I don't want to screw around with minor distros and I don't trust arch.
cedwards: <u>jdoe</u>: then I guess you're screwed.
jdoe: yep.
cedwards: why is it that you don't trust arch?
jdoe: so my options are basically centos, fedora, *buntu and debian.
<br> the first two are polished but upgrading them sucks, the kubuntu sucks, and debian is stale :/
***: mdg has joined #arpnetworks
mdg: Hi, I currently have an OpenBSD VPS with you guys, but I would like to switch it to Arch Linux, is this possible ?
cedwards: <u>mdg</u>: heh. I just did that one one of my machines.
<br> <u>mdg</u>: it's possible. you'll need to submit a support@ request, and there is some manual config to be done during install.
mdg: <u>cedwards</u>: were you doing the $20/month (and did your pricing change?)
cedwards: <u>mdg</u>: I am doing the $20 (I have two machines). No price change, just a support request for him to reprovision is all.
jdoe: <u>cedwards</u>: I might give fedora a shot.
mdg: <u>cedwards</u>: awesome, thanks
cedwards: <u>mdg</u>: the reprovisioning will require your current system be destroyed, so make sure you've got what you need.
<br> <u>mdg</u>: ..and I'll document on the wiki the manual tweaks required to get an Arch machine running properly.
mdg: sounds good
jdoe: <u>cedwards</u>: sorry, distracted before. My beef with arch is that I'm not sure how big the maintainer community is.
<br> for all I know it's just some dude like Slackware.
cedwards: <u>jdoe</u>: 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.
<br> everything goes through -testing before it goes public.
<br> and what I've been doing is compiling the entire repository in a chroot, helping ensure each package is compatible with the rest.
mdg: jdoe, its a good size for the size of the community. There are TUs which aid in package maintenance as well
cedwards: <u>mdg</u>: irc is very active, although it seems to be 12yr olds.
Wraithan: yeah heh
<br> i used to spend a lot of time in the arch channel it has changed a ton from when i started with arch
bob^^: never tried arch
<br> i've mostly been on debian in my linux experience
<br> i tend to break it :/
Wraithan: 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
-: mdg recalls seeing Wraithan in -offtopic
mdg: The fun thing about Arch is that the community doesnt take itself too seriously
Wraithan: <u>mdg</u>: i am the founder of the -ot renegade channel
cedwards: and everything is so stinking simple. it's great
mdg: renegade ?
Wraithan: plol
<br> Well, we had a issue with the ops in #archlinux-offtopic so we started another channel that everyone was an op in
<br> then that blew up because the founder of that one went all nazi too
mdg: who was the founder of that one ?
Wraithan: so I started ##lessthanthree and that's our new home
<br> daedhel
mdg: heh
Wraithan: how long have you been an archer mdg /
<br> ?
<br> 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[
mdg: <u>Wraithan</u>: ~ 3 years
<br> 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
<br> but the archwiki, you cant beat it
Wraithan: I use the archwiki when troubleshooting stuff on the gentoo and ubuntu servers at work
setient: hi guys!
***: schmir has quit IRC (Ping timeout: 240 seconds)
BarberRonny: HELLLOO
mdg: oh hey
jdoe: <u>mdg</u>: TU = trusted user or similar? Why should I trust them? :P
Wraithan: <u>jdoe</u>: because the developers do
<br> <u>jdoe</u>: why do you trust the developers of your distro?
bob^^: lessthanthree is a great name :)
Wraithan: http://lessthanthreesoftware.com
<br> That's my blog
<br> lol
bob^^: nice :)
<br> love the last post
<br> had a very similar experience
<br> people think websites take like two seconds :(
Wraithan: http://www.teamfortress.com/macupdate/ -- for all you macf-- er users :)
jdoe: <u>Wraithan</u>: TU implies some forum rat, debian has ridiculous bureaucracy, redhat/suse have actual companies overseeing that.
<br> so yeah, there's a difference.
Wraithan: redhat/suse are crap
bob^^: +1
Wraithan: TU is more than forum rat, these are people who have maintained packages in the AUR which is a user based repository for packages
bob^^: i remember using redhat about 12 years ago
<br> it was 'ok' then
<br> in fact, i think my first linux experience was suse
<br> but then i was shown freebsd, and i must admit, i've absolutely *never* looked back
Wraithan: 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
bob^^: probably helps that i was shown by the chap who used to be the official freebsd documentation editor
jdoe: redhat isn't crap for what it is.
Wraithan: <u>jdoe</u>: it hurts the linux world.
jdoe: having a stable platform for production use? how terrible.
Wraithan: 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
<br> yeah, doesn't sound bad at all.
<br> python 2.3 and 2.4 should be dead.
<br> 2.7 is coming out next month
jdoe: heh
<br> see, here's the thing.
<br> suppose I have an app written for python2.3 (and I do indeed have just such an app, although not on redhat)
<br> my options are to fix the app for whatever version redhat/debian/whoever decides to ship.
<br> ... or I can have that platform supported and not waste the time and effort.
<br> that's a no-brainer.
Wraithan: waste?
jdoe: yes, waste.
Wraithan: There is a reason the python language has progressed in ways that aren't backwards compatible
jdoe: yes, but none of that invalidates the way things were previously done.
<br> it worked before, and it will continue to work for the foreseeable future.
<br> so yes, it's a waste for us to fix the app.
Wraithan: maybe you should have kept up with python
<br> it isn't bad porting from 2.3 to 2.4
<br> or 2.4 or 2.5
jdoe: right, but it takes more than zero effort, right?
<br> and the benefits from my POV are negligible. Things might perform slightly better, but my current setup is never going to perform worse.
Wraithan: 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
jdoe: what effort?
<br> it's supported for years.
<br> rhel does 7 years of support for major versions.
Wraithan: additional effort because only old libraries which are also unsupported now
<br> so you are rebuilding everything
jdoe: true, but 7 years is a long time, after that long I probably would be anyway.
Wraithan: but you are chosing to ignore that cost
jdoe: and the difference is it's on my timeline, not because some distro EOL'd a version after a year.
Wraithan: heh, yeah sure
jdoe: to each their own, but I never thought I'd hear someone call stability a *failing* of linux..
Wraithan: you and every other programmer who has said, we have plenty of time, we can just update it later
<br> funny thing is the cost of updating grows over time
jdoe: I'm not a programmer, I'm a sysadmin.
Wraithan: Ah
jdoe: I've never met a programmer who wouldn't jump at the chance to upgrade to python 3.14
Wraithan: Not quite a bad but almost
-: Wraithan is a programmer
jdoe: for me, show me a tangible, immediate benefit or gtfo ;)
<br> well no, not immediate.
<br> I'm low on blood sugar and rambling now. I need food.
bob^^: :)
<br> i still haven't got stuck in to python
<br> i bought the book
<br> *books
<br> now they are out of date
<br> :(
Wraithan: what version do they teach?
bob^^: sec
<br> 2.0 hehe
<br> i'm sure i wouldn't have any trouble learning the new stuff though
Wraithan: 2.0?
bob^^: that's what it says
<br> o'reilly books, from at least, hmm, four years ago?
Wraithan: book is 10 years old?
bob^^: maybe more than four years
<br> 'covers python 2' is what is says :/
Wraithan: oh
<br> ok
<br> probably 2.4
bob^^: i find that i need a project to learn a new language
<br> never really found a project
<br> i was going to write a radius server in python but 'hmmmmmmm'
<br> maybe with twisted or sth
Wraithan: diesel > twisted
<br> lol
bob^^: meh
<br> don't really know hehe
Wraithan: twisted is not like writing python it is like writing twisted
bob^^: i guess i'd want a new 'thread' for every inbound UDP packet
<br> but as i say, never had to actually do anything with python so :)
<br> i wrote a radius client in php a few years ago, that was fun
<br> that was before i ended up writing a usenet binary grabber in php with rate limiting
<br> fun projects, now i hate php
up_the_irons: wth does my /etc/event.d/ttyS0 work in Jaunty but not Lucid
***: Jestre has quit IRC (Read error: Connection reset by peer)
<br> Jestre has joined #arpnetworks
jdoe: dunno
<br> I hate writing for upstart though.
bob^^: i don't really get why it matters that a box takes a little while to start
<br> hence i don't really get the point of upstart
jdoe: well it makes init dependencies more sane.
<br> and it gives you some easier triggers than what init allowed.
<br> ... but users don't care about that so they boast about how instead of taking 15 seconds to boot now it takes 14.
-: Wraithan uses a BSD style init with linux
bob^^: bsd style makes more sense to me
<br> i can't even begin to understand runlevels, especially in the context of 'today'
<br> and tbh i don't really care how long a restart takes
<br> but that's probably because we have redundant everything
jdoe: even on a lone machine I don't care
bob^^: same, tbh
jdoe: init is the fastest part of the boot anyway
<br> I've got to wait minutes for the controllers to init.
bob^^: yup
<br> dell servers tend to take even longer than that tbh
jdoe: been a while since I had to deal with one.
bob^^: tbh, when you look at how long it takes to restart something like a cisco 6500 with something like a sup720
<br> everything comes into perspective :)
<br> 10+ minute downtime right there
jdoe: indeed.
up_the_irons: new IPv6 policy for new VPS setups:
<br> " A /48 IPv6 block has been allocated to your site as recommended by RFC 3177 and RFC 5375.
<br> However, only the first /64 is directly connected (assigned) to your VLAN.
<br> Should you require use of the entire /48 at this time, we will route it to you over a link-local address.
<br> Please email support@arpnetworks.com to set this up. "
<br> this will appear in IP Block detail in the Portal for new setups
<br> I think it is a saner default
bob^^: makes perfect sense :)
up_the_irons: and the info appears a little different, so as to make this clear
<br> putting a /48 on the VLAN always made me uncomfortable
<br> toddf will like this change ;)
bob^^: hehehehe :)
toddf: YAYAYAYAYAYAYAYAYAYAYAYA
<br> the next sane default would be a link local address for the gateway
up_the_irons: LOL
bob^^: :D
RandalSchwartz: what is the effect of this change?
<br> I'm not following
up_the_irons: <u>toddf</u>: 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
bob^^: that makes sense, up_the_irons
<br> ipv6 is a confusing beast
RandalSchwartz: I mean, what can you do with the new setup that you can't do with the old one
<br> coudln't I always say that my em0 was /64
<br> and then create other nets near it?
up_the_irons: <u>RandalSchwartz</u>: nope
<br> <u>RandalSchwartz</u>: b/c the /48 was on the wire
bob^^: the whole /48 was routed to your VPS previously, no?
Wraithan: https://twitter.com/IPv4Countdown
up_the_irons: <u>RandalSchwartz</u>: the /48 would have to be routed to you, over say a link-local address, for you to subnet it further
<br> <u>RandalSchwartz</u>: 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
RandalSchwartz: well, wouldn't my em0 act as a proxy arp them?
<br> you'd route all of the /48 to my em0, then I could further route it
up_the_irons: <u>RandalSchwartz</u>: yes, if you wanted that, sure
<br> <u>RandalSchwartz</u>: not sure wrt proxy arp
RandalSchwartz: yeah - so I don't see what the change buys me yet
<br> as long as I'm not putting two pieces of the /48 in entirely disjoint places
<br> but I can't, because the global routing table can't handle that
toddf: <u>up_the_irons</u>: 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
up_the_irons: <u>RandalSchwartz</u>: you shouldn't. with only a couple VPS's, there is really no need to further subnet a /48
<br> <u>RandalSchwartz</u>: unless you want to do some tunnel's and have individual /64's for the tunnels
toddf: <u>randalschwartz</u>: this isn't about arp, v6 doesn't have arp!
RandalSchwartz: how does it map an address to ether then?
toddf: ndp
up_the_irons: 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
toddf: v6 does multicast
bob^^: yeah, indeed
toddf: ping6 -n -w ff02::1%em0
bob^^: i like the new default :)
<br> makes sense :)
toddf: that'll get you all kame based systems on the wire, unless firewalled
<br> ping6 -n -w ff02::2%em0
up_the_irons: <u>toddf</u>: roger
toddf: that'll get you all sysctl net.inet6.ip6.forwarding=1 kame based systems on the wire, unless firewalled (read: all your routers)
<br> the ff02::/8 is a special multicast subnet .. compare with 224.0.0.0 on ipv4, but always present in v6
<br> it permits link local discover of addresses, both global and link local
up_the_irons: yeah
RandalSchwartz: 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 ?
toddf: so a combo of ff02::/8 multicast and fe80::/8 link-local addresses come into play to discover local addresses
<br> precisely
RandalSchwartz: ahh. I thought I could do that before
<br> so I'll want mine changed. :)
bob^^: oh cool
toddf: 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
bob^^: i hadn't thought of that
toddf: what the new default permits
<br> is one /64 for the link local of your vps
<br> then the rest of the 65535 /64's just routed to your vps
<br> so you can then do with them what you want, including assign them to lo1 lo2 lo3 or whatever
RandalSchwartz: yeah, ok, sign me up!
up_the_irons: wow, i just did "ping6 -n -w ff02::1%em0" on a test VPS
toddf: or .. if you enable forwarding for v6, you can setup tunnels to remote systems to utilize the address space
up_the_irons: interesting!
RandalSchwartz: if I change my /48 to a /64 right now, will it break anythin?
<br> in anticipation of the change?
toddf: the -w is the `kame specific' option, w/out it even linux and cisco respond
up_the_irons: it sees the router and the console server. i wonder why the console server is in there...
toddf: <u>randalschwartz</u>: changing to a /64 will not break if your v6 addresses lie within that /64 including your upstream gateway
<br> now if your upstream gateway were the link local of the upstream router, the 'including your upstream gateway' goes away in the above sentence
up_the_irons: oh, same vlan, f'in duh
RandalSchwartz: yeah - that's true so far
toddf: the %em0 means 'this ethernet segment attached to em0'
up_the_irons: 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
toddf: <u>randalschwartz</u>: 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
RandalSchwartz: so what interface does the remainder of the /48 come in on?
toddf: <u>randalschwartz</u>: its routed to you
RandalSchwartz: I'd take v6 down and up
<br> as in, it also comes in via em0?
toddf: 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
RandalSchwartz: ahh, but I can say 10.0.0.3/2 goes over there ==>
toddf: just rinse and recycle with v6 subnets of /64 and /48 instead of /24 and /16
RandalSchwartz: since I'm now only 1,2
toddf: well, 10.0.0.0/24 ought to be on the native wire
<br> 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
RandalSchwartz: ahh. I mean 10.0.1/24 is "over there"
<br> right
<br> yeah - that's what I was getting at
<br> upstream router would send any of 10/16 to me
<br> but only 10/24 is considered "me"
<br> by "me"
toddf: and the specific link local of 10.0.0.0/24 over-rides the route of the 10/16
RandalSchwartz: yeah, that's how I thought it was working now anyway
toddf: what we had for a previous default is 10/16 on the wire, period
<br> equivalent mind you
RandalSchwartz: but if I assigned /24 to em0, and 10.0.1/24 to lo1
<br> wouldn't it just do the right thing?
<br> I mean, why does upstream care?
toddf: previously, no
<br> the wire would do arp requests for 10.0.1.X thinking its on the local link
RandalSchwartz: ahh...
<br> it's starting to sink in
<br> ok yes, I want this change. :)
toddf: 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 ;-)
<br> not sure if v6 even has 'proxy ndp'
<br> while the term 'link local' originates from v6, you get the same concepts in v4 `within the subnet on the wire'
RandalSchwartz: email to support done. :)
up_the_irons: <u>toddf</u>: it does indeed do proxy ndp, which was required on some tunnels for customers when I put the whole /48 on the wire
toddf: <u>up_the_irons</u>: 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*
RandalSchwartz: as long as I'm not using any address above the /64, it doesn't matter how I'm set up, right?
<br> at least so I have to worry about a transition
up_the_irons: <u>toddf</u>: cool!
toddf: <u>randalschwarts</u>: technically no, but a mismatch in prefixlen from router to vps cannot be a thing to expect no problems from ever ;-)
RandalSchwartz: Right. I'll fix it as soon as I hear I've been changed
toddf: 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
RandalSchwartz: in theory then, I could assign each jail its own /64
<br> and nat the ipv4, right?
toddf: (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...)
up_the_irons: [arin-announce] IANA IPv4 Free Pool is Now at 6.25%
<br> wow
toddf: yes you could
up_the_irons: it was 10% 6 months ago!
RandalSchwartz: "imminent collision... sound the klaxons"
<br> "followed shortly by the failtrombone"
<br> "network_ipv6 stop" doesn't do what I thought
<br> but "ifconfig em0 inet6 dead:beef:babe::/64 does
<br> fixed up the routing too, looks like
<br> I don't see any /48's in there now
up_the_irons: <u>toddf</u>: 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)
toddf: initiall you'll have customers with a single vps
<br> you'll have a /64 on the wire
<br> and your router is the default upstream
up_the_irons: well yes, that's the new default now
toddf: if they get more vps's they can choose to put them all in that one /64
<br> the rest of the /48 can be routed as a group to one vps or split up amongst several vps's
up_the_irons: right right, but should they want the /48 routed... then what?
RandalSchwartz: presuming they're all on the same host box
toddf: if they're wanting failover they can put the link local address into a carp group between vps's
up_the_irons: roger
RandalSchwartz: carp diem!
<br> fish of the day!
up_the_irons: 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
toddf: you can split the /48 into 65535 /64's if they really want 65535 individual vps's with individual /64's
<br> not that your routing table would be happy but it could be done theoretically
up_the_irons: <u>toddf</u>: right, that's just the "manual" (email support) way of doing it
toddf: if you wanted an automated way of splitting it up, ospf comes to mind as superior to rip6
up_the_irons: <u>toddf</u>: 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
<br> i take it
toddf: I may use rip6 for my upstream tunnel to iijlabs which wrote kame, but thats the only place I've used either
<br> one mac address on the link must respond as a router for the /48 yes
up_the_irons: roger, that's all i wanted to clarify
toddf: they could have multiple vps's responding to that one mac address per carp(8) or other similar technology
<br> note that 'fe80::X' addresses can also be aliased
<br> $ ifconfig vlan8
<br> <u>vlan8</u>: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> 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
<br> blah stupid irssi
<br> $ ifconfig vlan8
<br> <u>vlan8</u>: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
<br> lladdr 00:0c:76:55:82:1b
<br> <u>description</u>: wifi-default
<br> inet6 fe80::20c:76ff:fe55:821b%vlan8 prefixlen 64 scopeid 0xd
<br> inet6 fe80::2%vlan8 prefixlen 64 scopeid 0xd
<br> $ ifconfig carp8
<br> inet6 fe80::200:5eff:fe00:108%carp8 prefixlen 64 scopeid 0x15
<br> inet6 fe80::1%carp8 prefixlen 64 scopeid 0x15
<br> inet6 2001:240:58a:2::1 prefixlen 64
<br> $ ps ax | grep rtadvd
<br> 21080 ?? Is 0:10.62 rtadvd carp3 carp6 carp8 carp13 carp14
<br> .. on a client system:
<br> $ ping6 -n -w ff02::1%rum0
<br> PING6(72=40+8+24 bytes) fe80::69%rum0 --> ff02::1%rum0
<br> 40 bytes from fe80::69%rum0: knetbook.fries.net.
<br> 37 bytes from fe80::1%rum0: carp1.fries.net.
<br> 37 bytes from fe80::2%rum0: carp1.fries.net.
<br> $ netstat -nr -f inet6 | grep def
<br> default fe80::1%rum0 UG 11 10546019 - 4 rum0
RandalSchwartz: toddf - so after the change to the link-local /48, what's my outbound default route going to look like?
toddf: 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
RandalSchwartz: my em0 is now /64, right?
toddf: <u>randalschwartz</u>: depends on if I talk up_the_irons into link local or global .. ;-)
RandalSchwartz: which would be better?
<br> I'm sure he's listening. :)
toddf: <u>randalschwartz</u>: in reality, anything thats on the link and subnets you have configured that the router responds to
<br> the `path with most options' is link local, the `path that mimics old v4 behavior better' is global
RandalSchwartz: my existing ::1 for example?
toddf: ::1 <=> 127.0.0.1
RandalSchwartz: I mean dead:beef:babe::1
<br> I just hate typing all that :)
toddf: this is my vps:
<br> $ netstat -nr -f inet6 | grep def
<br> default fe80::5054:ff:fe27:9007%em0 UGS 14 3667 - 8 em0
<br> $ cat /etc/mygate
<br> fe80::5054:ff:fe27:9007%em0
<br> 208.79.89.89
<br> $ cat /etc/hostname.em0
<br> inet6 2607:f2f8:1800::2 64
<br> inet 208.79.89.90 255.255.255.252
RandalSchwartz: what is that fe80 address?
<br> I have fe80::5054 as well
toddf: fe80::/8 is `link local' aka each v6 enabled link has the subnet but those are non routable addresses
RandalSchwartz: is that link local based on MAC addr?
toddf: ff02::/8 is `multicast' aka each v6 enabled link has the subnet but those are non routable addresses, plus if you access one it is sent to the whole ethernet segment
<br> it can be based on mac address
<br> however, at isc.org for example, they do this:
<br> /etc/hostname.em0:
<br> inet6 fe80::1234
<br> rtsol
<br> and get a global v6 with ::1234 for that host
<br> manually numbering hosts lower /64 bits but having the upper /64 bits auto configured
<br> that only works if you do rtadvd (router) and rtsol (client) but it can be useful, some discourage since if you nubmer things from 0 its easy to discover hosts, but well, whatever
RandalSchwartz: ok - so I'll just let my eyes glaze over, and replace ipv6_defaultrouter=2607:f2f8:3080::1 with whatever up_the_irons says :)
up_the_irons: <u>RandalSchwartz</u>: yep :)
toddf: there are also some privacy things to change the link local also, randomly generate etc, the mac address is the default source of the lower /64 bits on a link local address though yes
RandalSchwartz: so the dead:beef:babe::1 address effectively goes away?
toddf: the thing to simply keep in mind is ... fe80::BLAH%em0 -> `on the local em0 link, link local addresses' .. ff02::BLAH%em0 -> `multicast on the local em0 link, link local addresses' .. 200X:BLAH -> global routable addresses
<br> if you can reach a system on the local link, you can route to it, therefore unless the link local of the remote system changes, your default route doesn't need to change even if both you and the router renumber
RandalSchwartz: I eman, doesn't the router need some v6 number?
<br> or can it just use a virtual interface name, like I use em0?
toddf: the router has a fe80::...%em0 number you can set as your default route yes
<br> `em0' is not an adddress its an interface
up_the_irons: <u>toddf</u>: hey, if I "ifconfig destroy vlanXXX" then "sh netstart vlanXXX" (with new settings in hostname.vlanXXX), will that bring up vlanXXX with the new settings? any side effects I should know about?
toddf: $ ping6 -n -w ff02::1%em0
<br> PING6(72=40+8+24 bytes) fe80::5054:ff:fe27:2122%em0 --> ff02::1%em0
<br> 40 bytes from fe80::5054:ff:fe27:2122%em0: 0.v.freedaemon.com.
<br> 44 bytes from fe80::5054:ff:fe27:9007%em0: s3.lax.arpnetworks.com.
<br> guess what, s3.lax.arpnetworks.com aka fe80::5054:ff:fe27:9007%em0 is my v6 router on my local link, and thats what I set my default route to, works fine
RandalSchwartz: so this is me - fe80::5054:ff:fe27:2232%em0: red.stonehenge.com.
<br> and this is the router - fe80::5054:ff:fe27:9007%em0: s3.lax.arpnetworks.com.
<br> and that's how we'll route to each other?
toddf: <u>up_the_irons</u>: I've been around way too long and you'll realize this when I say this, but I am in a habit of 'ifconfig if down' 'ifconfig if destroy' 'sh /etc/netstart if' .. it used to cause issues sometimes, probably fixed by now, doesn't change my `be safe' habits
<br> <u>randalschwartz</u>: that'd be my recommendation, yes
RandalSchwartz: will my number ever change?
up_the_irons: <u>toddf</u>: roger
toddf: I'm just a v6 guru client, up_the_irons can take the he.net attitude route and force global addresses to be in place and ping'able before the rest of the v6 is routed through, but he's turning out to not be so blind
up_the_irons: <u>toddf</u>: yeah i'm trying not to go that way; i'd rather do it proper now then have a thousand interfaces to change later
toddf: <u>randalschwartz</u>: if your em0 macaddr changes, it would be because up_the_irons set a different cmdline to his kvm instance; you can always do 'ifconfig em0 inet6 fe80::5054:ff:fe27:2232' on your em0 interface as the 1st thing done with it, and it'll use that as the link local
<br> regardless of up_the_irons mac address tomfoolery
RandalSchwartz: but I can't just say "use em0 as my default route?"
<br> you can do that in v4
up_the_irons: <u>toddf</u>: or I could use fe80::1 and fe80::2, which is simpler, but I'm not sure what the ramifications could be down the road
toddf: he.net uses 2 global addresses in a point to point link when they could use link local, for every tunnel they have, seems like a waste of precious memory in their cisco concentrators ;-) hehehehe
<br> <u>randalschwartz</u>: if it is a point to point link, you can, you can't broadcast to a v4 router on an ethernet segment and hope it picks up the packets and routes them, you need a router destination as far as I know
RandalSchwartz: ok
toddf: well, maybe if the v4 router responds to the broadcast address, but that seems rather hockey
<br> I've configured `ip subnet zero' tomfoolery before, its way way way sad and strange
<br> at 1and1 hosting for example, the openbsd net config is like this:
<br> /etc/hostname.nfe0:
<br> inet 74.208.X.X 255.255.255.255
<br> !route add -llinfo -iface -net 10.255.0.0/16 10.255.255.1 -ifp nfe0
<br> inet alias 74.208.X.X 255.255.255.255
<br> .. etc ..
<br> /etc/mygate:
<br> 10.255.255.1
<br> Destination Gateway Flags Refs Use Mtu Prio Iface
<br> default 10.255.255.1 UGS 112 1554310729 - 8 nfe0
<br> 10.255/16 link#1 UCLS 1 0 - 8 nfe0
<br> 10.255.255.1 00:00:0c:07:ac:00 UHLc 3 0 - 8 nfe0
<br> thats just hockey .. but it lets them assign individual /32's to individual colos w/out wasting netmask and broadcast on each vlan .. such a pita though
<br> finding arpnetworks that does things .. right .. in so many ways prior to my `suggestions' .. was a breth of fresh air
<br> I even have a colo facility here in Oklahoma City that thinks putting all ethernet segments on the same vlan is ok with filter rules on the switch *sigh* .. I wish I could calculate the broadcast traffic they rack up against peoples bandwidth as a result ..
RandalSchwartz: so technically, if both upstream and I route via link local, he doesn't even need to assign the /64 as "live", right
toddf: so, its been fun folks, but I have someone who wants to see me at home -> http://todd.fries.net/pub/IMG00550-20100610-1103.jpg ;-) (incase anybody was wondering why I've been silent for the last 1.5 months, more or less..)
RandalSchwartz: just route the entire /48 to me, and I can either respond, or route it along?
toddf: pretty much, yes
RandalSchwartz: that would be easier to understand
toddf: however, if he has an ip on his router for the lowest /64 in your /48 .. his router would expect your global addresses to appear on the link also
RandalSchwartz: rather than having a special /64 that acts differently from teh rest
<br> ok
<br> well - do the right thing, whatever it is.
<br> I have to bounce from here.
toddf: aka its as if you had a 192.168.0.0/24 for routing, router = 192.168.0.1, you = 192.168.0.2
<br> if he just did: route add 10.0.0.0/16 192.168.0.2
<br> then you could have 10.0.X.X anywhere inside your vps or tunnel it out etc
<br> however if he also had an alias on his router
<br> 10.0.0.0/24
<br> his router would look for 10.0.0.0-10.0.0.255 on the link
<br> 10.0.0.1/24 .. rather
RandalSchwartz: ok - I'll be back online in a few... just gotta relocate to the happy hour location
-: RandalSchwartz wanders off
toddf: I'm explaining this all in terms of v4, but if you s/192.168.0./fe80::/g and s/10.0.0.0/16/2607:f2f8:XXXX::/48/g you start to get the idea
<br> I'm heading home, so likely won't be responsive most of the evening
up_the_irons: <u>toddf</u>: thanks for all the great info
***: fink has joined #arpnetworks
RandalSchwartz: ok - back
<br> but it looks like my 6 is gone
up_the_irons: <u>RandalSchwartz</u>: yeah i'm making the changes now
RandalSchwartz: Oh- I guess not
<br> it responds to pings
<br> do I need to use an alias to make em0 also be fe80::2/64 ?
<br> ... ipv6_addrs_em0="2607:f2f8:3080::/64 fe80::2/64"
<br> would that work?
***: RandalSchwartz has quit IRC (Ping timeout: 240 seconds)
<br> RandalSchwartz has joined #arpnetworks
RandalSchwartz: well - I've managed to screw up my v6
<br> em0 has inet6 fe80::2%em0 prefixlen 64 scopeid 0x1
<br> right?
bob^^: i never knew a 403 was quite so time consuming toddf ;)
RandalSchwartz: but it still says the way to fe80::2 is via lo0
<br> that can't be right
<br> how do I convince it to send via em0?
<br> and I can't ping6 fe80::1, so I surely can't add that as a default route
<br> what do I do next?
<br> ahh - via em0
<br> yeah, that's doing it
<br> now I have default route out
<br> and ping in!
<br> this implies ipv6_defaultrouter=fe80::1%80
<br> errr ipv6_defaultrouter=fe80::1%em0
<br> and ipv6_addrs_em0="2607:f2f8:3080::/64 fe80::2/64"
<br> can anyone verify that?
<br> is this mic on?
<br> hello?
-: bob^^ hears a faint echo
RandalSchwartz: I don't see toddf or up_the_irons talking back at me
up_the_irons: <u>RandalSchwartz</u>: i'm still trying this on my own vps
RandalSchwartz: Ahh. lo0 is already fe80::1%lo0
<br> so maybe fe80::1 is a bad choice
up_the_irons: yeah i'm just noticing this also
RandalSchwartz: your default route will have to be explicitly fe80::1%em0
<br> which is why I went off the grid
up_the_irons: finally found the route command: sudo route add -inet6 default fe80::1 -prefixlen 64
RandalSchwartz: no that's not enough
<br> not for freebsd
<br> since there's already an fe80::1
<br> on lo0
up_the_irons: yeah i deleted those ;) but yeah i see what you're saying
RandalSchwartz: maybe you should pick something like fe80:feed:feed:feed:feed
<br> and for my end fe80:f00d:f00d:f00d:f00d:f00d :)
up_the_irons: LOL
RandalSchwartz: or actually, it'd be cuter the other way around
<br> anyway, I have v6 at the moment
<br> Not sure if I did the right thing for a reboot, but it won't matter, as I say
<br> actually fe80:feed:feed:feed::1 and :;2 would be cool
<br> with a /64
<br> it'd clearly stand out in the docs :)
up_the_irons: <u>RandalSchwartz</u>: i'm going to change it to the auto-assigned link local
RandalSchwartz: but what if that changes?
<br> oh duh, you control both ends of that. :)
up_the_irons: yup
RandalSchwartz: this is a virtual world
up_the_irons: <u>RandalSchwartz</u>: what is the auto-assigned one btw
RandalSchwartz: ... fe80::5054:ff:fe27:2232
up_the_irons: thanks
RandalSchwartz: and yours is fe80::5054:ff:fe27:9007
<br> looks like it's derived from the linklayer
up_the_irons: <u>RandalSchwartz</u>: yes, use "fe80::5054:ff:fe27:9007" as your default gateway
RandalSchwartz: so should I go ahead and update that for mine?
<br> ok
up_the_irons: <u>RandalSchwartz</u>: where did it say that btw?
RandalSchwartz: I looked at "ndp -a"
<br> that's like "arp -a" for ipv6
up_the_irons: ah right
RandalSchwartz: ok - after the change, no v6 for now
up_the_irons: <u>RandalSchwartz</u>: what does your interface and routing table look like?
RandalSchwartz: I left em0 off
<br> hold on
<br> nope. still can't ping 9007
<br> ... default fe80::5054:ff:fe27:9007%em0 UGS em0
up_the_irons: can i see your em0
RandalSchwartz: ... inet6 fe80::5054:ff:fe27:2232%em0 prefixlen 64 scopeid 0x1
<br> oh wait, there might be a bad route still
<br> hmm. I have an fe80::/10 via lo0
<br> otherwise it looks like it *should* work
<br> I can ping myself at the %em0
up_the_irons: yeah i'm still trying to get mine own test vps set up
RandalSchwartz: rats. the other one *was* working :)
up_the_irons: yeah, gotta be something simple...
<br> ah, the %em0 is important
<br> ping6 fe80::5054:ff:fe27:9007%em0
<br> that works for me
<br> but not without
RandalSchwartz: yes
<br> because of that %lo0 entry
up_the_irons: ah!
<br> default fe80::5054:ff:fe27:9007 UGS lo0
<br> yeah
RandalSchwartz: so maybe you should pick something that isn't in fe80::/10
up_the_irons: it says lo0
RandalSchwartz: see there ya are
up_the_irons: nah, fe80:: is _the_ link-local subnet
RandalSchwartz: ok
up_the_irons: not sure why freebsd puts the /10 on lo0
RandalSchwartz: but you have to fully qualify which link :)
fink: hi guys
<br> anybody run voip stuff on their arps?
up_the_irons: the auto-assigned link-local addresses are supposed to be the ones to route over. if i get rtadvd running, then your box _should_ automatically get the default route, etc...
RandalSchwartz: so do you think it should work now?
up_the_irons: <u>RandalSchwartz</u>: i'm rebooting mine and i will see...
RandalSchwartz: well, did you change your end pointing at me?
<br> to use my virt net?
<br> virt if?
<br> I think that's what I was missing before
<br> you've got confusion at your end about fe80::/10 like I did
up_the_irons: <u>RandalSchwartz</u>: my end pointing at you is now: fe80::5054:ff:fe27:2232
RandalSchwartz: yeah, I can't hit 9007 yet
<br> with %someif ?
up_the_irons: <u>RandalSchwartz</u>: perhaps if we did fe80::2%em0 (qualified it), it would have worked, before, but oh well
<br> <u>RandalSchwartz</u>: try -- ping6 fe80::5054:ff:fe27:9007%em0
RandalSchwartz: it *did* work before
<br> I am. fail.
up_the_irons: lol
<br> ok, i got my test vps working
RandalSchwartz: so what else did you change?
<br> I have default fe80::5054:ff:fe27:9007%em0 UGS em0
up_the_irons: i only have a /64 routed to it, but /48 would be similar
<br> here's my rc.conf:
<br> ipv6_enable="YES"
<br> ipv6_defaultrouter="fe80::5054:ff:fe27:9007%em0"
<br> ipv6_ifconfig_em0="2607:f2f8:d00d::2 prefixlen 64"
<br> i have:
<br> default fe80::5054:ff:fe27:9007%em0 UGS em0
RandalSchwartz: yes - that's what I have
up_the_irons: ok, check
<br> what does your ifconfig em0 look like?
RandalSchwartz: ... inet6 fe80::5054:ff:fe27:2232%em0 prefixlen 64 scopeid 0x1
<br> inet6 2607:f2f8:3080:: prefixlen 64
<br> I cannot ping fe80::5054:ff:fe27:9007%em0
<br> my default gateway
<br> so maybe packets aren't coming back to me
<br> do you have the right interface on my return route?
up_the_irons: yeah strange
<br> yeah
<br> your vlan on my end:
<br> <u>vlan232</u>: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
<br> lladdr 52:54:00:27:90:07
<br> <u>vlan</u>: 232 priority: 0 parent interface: em0
<br> <u>groups</u>: vlan
<br> inet6 fe80::5054:ff:fe27:9007%vlan232 prefixlen 64 scopeid 0x122
RandalSchwartz: and your route?
<br> netstat -rn | grep vlan232 :)
up_the_irons: 2607:f2f8:3080::/48 fe80::5054:ff:fe27:2232%vlan232 UGS 0 0 - 48 vlan232
<br> fe80::%vlan232/64 link#290 UC 0 0 - 48 vlan232
<br> fe80::5054:ff:fe27:9007%vlan232 52:54:00:27:90:07 UHL 0 0 - 48 lo0
<br> ff01::%vlan232/32 link#290 UC 0 0 - 48 vlan232
<br> ff02::%vlan232/32 link#290 UC 0 0 - 48 vlan232
RandalSchwartz: can you ping me?
<br> oh wait.
<br> I think I see it
<br> no no
<br> yeah, I'm routed to :9007
up_the_irons: no i can't ping you
RandalSchwartz: wait - where's the route to my /48
<br> oh - first line
up_the_irons: yeah
<br> regardless of /48, we need to see why the local link isn't pinging :)
<br> this probably won't make you feel better, but to get mine working, i rebooted the vps
RandalSchwartz: sure - noidea
<br> i'd rather not reboot, of course
up_the_irons: yeah
RandalSchwartz: ahh, screw it... I'll try a reboot... but let's verify my rc.conf
<br> .. fe80::5054:ff:fe27:9007%em0
<br> oops.
<br> ipv6_enable=YES
<br> ipv6_gateway_enable=YES
<br> crap
<br> can't paste here
up_the_irons: hehe
RandalSchwartz: ... ipv6_enable=YES
<br> ... ipv6_defaultrouter=fe80::5054:ff:fe27:9007%em0
<br> ... ipv6_addrs_em0="2607:f2f8:3080::/64"
<br> ... ipv6_gateway_enable=YES
<br> and off we go... reboot land
up_the_irons: <u>RandalSchwartz</u>: try /48
RandalSchwartz: oops.
<br> yeah, lemme fix
up_the_irons: <u>RandalSchwartz</u>: just to be consistent, until we know the link local works
RandalSchwartz: didn't help
<br> but rebooting
up_the_irons: k
infrared: freebsd? why not just /etc/rc.d/network restart ?
up_the_irons: <u>infrared</u>: we're having problems with new ipv6 config
***: RandalSchwartz has quit IRC (Remote host closed the connection)
infrared: o
up_the_irons: there we go!
<br> PING6(56=40+8+8 bytes) fe80::5054:ff:fe27:9007%vlan232 --> fe80::5054:ff:fe27:2232%vlan232
<br> 16 bytes from fe80::5054:ff:fe27:2232%vlan232, icmp_seq=73 hlim=64 time=0.964 ms
<br> 16 bytes from fe80::5054:ff:fe27:2232%vlan232, icmp_seq=74 hlim=64 time=0.54 ms
<br> 16 bytes from fe80::5054:ff:fe27:2232%vlan232, icmp_seq=75 hlim=64 time=0.543 ms
bob^^: reboot fix it ?!
***: RandalSchwartz has joined #arpnetworks
RandalSchwartz: v4 came up, v6 still no go
up_the_irons: <u>RandalSchwartz</u>: but i can ping you now
<br> PING6(56=40+8+8 bytes) fe80::5054:ff:fe27:9007%vlan232 --> fe80::5054:ff:fe27:2232%vlan232
<br> 16 bytes from fe80::5054:ff:fe27:2232%vlan232, icmp_seq=0 hlim=64 time=0.496 ms
<br> 16 bytes from fe80::5054:ff:fe27:2232%vlan232, icmp_seq=1 hlim=64 time=0.457 ms
RandalSchwartz: and I you
<br> now why aren't the routes working further out
<br> ahh - my external address didn't get assigned
up_the_irons: ah
RandalSchwartz: bingo
<br> I have pingo!
<br> correct ip6 when outbound as well
up_the_irons: :)
RandalSchwartz: and yup, traceroute6 to my laptop works
<br> (gotta love teredo
<br> ipv6 anywhere
up_the_irons: now you can assign /64's around to different devices
bob^^: ugh, unless you're behind a hotspot
RandalSchwartz: indeed
bob^^: then it goes mental
RandalSchwartz: no - I'm behind a hotspot
<br> and it's working fine
bob^^: uh huh
RandalSchwartz: if you're *two* layers down, that's hard
bob^^: a hotspot where you have a public address without having been logged in
<br> a public ipv4
<br> it goes nuts
RandalSchwartz: oh
bob^^: :)
RandalSchwartz: never seen that
bob^^: it's unusual, tbh :)
RandalSchwartz: ok - looks like all is good
<br> thanks for helping me diagnose it
<br> too bad it took a reboot, but that fixed it
<br> I don't see anything obviously different in the route table or the ifconfig
<br> but there ya go
infrared: uptimes shmuptimes
RandalSchwartz: oh - I see it!
<br> I now have a route for fe80::%em0/64
<br> didn't ahve that before
<br> that would have done it
<br> without that, there would have been no route to the router
up_the_irons: <u>RandalSchwartz</u>: yeah, all those little things get set up by /etc/rc and we forget we have to do it
<br> manually
<br> if no reboot is desired
RandalSchwartz: indeed
<br> anyway, all good now
<br> I can move on to the next most important task :)
fink: hi RandalSchwartz
RandalSchwartz: hey fink
up_the_irons: <u>RandalSchwartz</u>: cool
***: amdprophet has joined #arpnetworks
amdprophet: <u>up_the_irons</u>: sent a support ticket thinger, i can't send e-mails to you directly because your e-mail server checks reverse dns
up_the_irons: <u>amdprophet</u>: lol, get that fixed ;)
RandalSchwartz: hey up_the_irons - did you see that he.net is now offering free reverse dns and secondary dns?
amdprophet: that's what the support ticket is about :P
up_the_irons: <u>RandalSchwartz</u>: nope
RandalSchwartz: yeah - up to 25 domains
up_the_irons: <u>amdprophet</u>: ah :)
<br> interesting
RandalSchwartz: so if someone is asking "where do I get offsite secondary", tell them he.net
infrared: <u>up_the_irons</u>: you're at he.net?
up_the_irons: <u>infrared</u>: ?
infrared: your machines
RandalSchwartz: no
<br> they're in a cage
<br> because they're wild
infrared: whoa
RandalSchwartz: the cage is a few blocks from me :)
toddf: <u>randalschwartz</u>: wonder what he.net is getting out of the free dns offerings ..
<br> publicity but ..
RandalSchwartz: more publicity
<br> yes
toddf: doesn't add enough in my book
RandalSchwartz: well - if you go to them for that
infrared: freedns.afraid.org++
RandalSchwartz: you might by transit from them
toddf: *shrug* guess automation makes it cheap enough
RandalSchwartz: buy
<br> yeah
toddf: if I were in the transit buying game, I'd be looking at quality and price points and nothing else
RandalSchwartz: Yeah - I have a half dozen things at at afraid
jdoe: <u>toddf</u>: free hosting or free lookups?
RandalSchwartz: I'll be moving them to he.net soon
jdoe: oh, hosting.
RandalSchwartz: he.net is also the biggest provider of teredo transit
<br> pretty much if you get on teredo, you're on he.net
amdprophet: <u>up_the_irons</u>: is there any chance you'll be able to delegate rdns to our nameservers tonight?
up_the_irons: <u>amdprophet</u>: yeah sure
RandalSchwartz: that's because, I think, teredo.ipv6.microsoft.net is in fact a he.net machine
amdprophet: sweet :D
RandalSchwartz: at least, it's just one hop from he.net
up_the_irons: <u>infrared</u>: my machines are in my own cage at CoreSite (aka CRG West, aka One Wilshire)
RandalSchwartz: One Wilshire is clearly labeled for a few miles distance :)
<br> My hotel room is on the 28th floor of the north tower of the Westin, however
<br> so I'm looking the wrong way each night. :)
<br> I'm facing pasadena
<br> and the dodgers stadium
<br> the bedroom has power outlets... down by the tv at the foot of the bed, and not up near the headboard
<br> so I asked for an extension cord
***: fink has quit IRC (Quit: fink)