how would I go about adding the link local IPv6 /128 route for backup out to eth1 so I dont have to do %eth1 on Ubuntu
I'm not sure I understand what you mean... If you're specifying a route to a LL address of *course* you have to include the interface.
To alter that behaviour would, at a minimum, require removing fe80::/8 from all other interfaces, and then whatever other hoops you have to jump through to get $tools to not require an interface suffix.
I was going by the trello suggestion: "If there were an IPv6 address for the backup server, all customers could add the address as a /128 to the routing tables on their VPS's to go via the link-local for the backup server over the dedicated interface."
(Now I'm trying to wrap my head around that)
perhaps the person who suggested that wanted a global unicast routable IPv6 AAAA record and not a link local
That could be
Which would annihilate the poor IPv6 router
it should only be acceible via backup interface
ie: not routed to IPv6 router
or global internet for that matter
up_the_irons: it seems like the IPv6 routing from the LA to the FFM location is somehow broken, traceroute ends at some HE router two hops or so from 2607:f2f8:0:102::4, while it works just fine from elsewhere
fIorz: yeah we're aware of that; it's because we're migrating to a new router and our NTT session used to carry a static route (which we migrated to the new router)
brycec: mnathani : the suggestion had mentioned link-local
mnathani: you always have to qualify a link-local address by %interface, if you have more than one link-local address
fIorz: I should set up a static to a different endpoint...
OK that was easy
It's working now
up_the_irons: New router... still running OpenBSD 3.9 though? :P
OpenBSD 5.9
About damn time :)
And just in time for 6.0 no less
Yeah
up_the_irons: now I am talking to a different webserver than via ipv4!? (in particular with a different(/worse) TLS setup)
Not sure which webserver you're referring to
Huzzah ARP. Company's main DC lost its Internet (apparently, I'm hearing it 3rd/4th/5th-hand) but the distributed/replicated services I stood up on our ARP instances are, of course, still chugging along.
up_the_irons: 2607:f2f8:0:102::4, or portal.a.c
I wonder if we're not proxying IPv6 from our SSL termination endpoint
mercutio: ^^
https://www.ssllabs.com/ssltest/analyze.html?d=portal.arpnetworks.com&s=2607%3af2f8%3a0%3a102%3a0%3a0%3a0%3a4
brycec: nice :)
fIorz: yeah that's how it was before we used a different SSL endpoint
yeah, IPv6 can do time travel :-)
(also, keeping the old endpoint available at all is a security problem, even if the DNS isn't pointing to it, as a MitM doesn't really care about DNS)
right
I've turned this into a Trello card under Known Issues:
https://trello.com/c/F6SS2RE1/15-portal-ipv6-endpoint-has-old-ip-should-proxy-through-newer-endpoint-with-stronger-ssl-termination
Votes welcome!
I am still confused about the /128 IPv6 Route as mentioned by the other Trello Card for backup
I was under the assumption that adding the route with the AAAA record would somehow eliminate the need to specify the interface %eth1 or whatever
No, that's not the case
All link-local addresses must be qualified, since the same subnet (fe80::/64) exists on all interfaces by default
I kept having to tell people our backup server IPv6 address, now at least the hostname can be queried
toddf: FYI, I wanted to acknowledge your feature request emails; I simply haven't had time to add them to Trello yet, but I will do so this week
up_the_irons: no worries, just .. much more experienced elsewhere these days, and I hope they are useful/constructive criticism ;-)
toddf: Yes, they are useful and appreciated!