In the UK Bytemark and Mythic Beasts both offer servers with native IPv6: http://www.bytemark.co.uk/ http://www.mythic-beasts.com/
Mythic Beasts even used to do a cheap deal on co-locating an AppleTV (running Linux!) due to its low power usage. Sent from my phone On 10 May 2012, at 18:39, Thomas Rieschl <[email protected]> wrote: > One of my servers is from Hetzner [1]. > It's located in Germany. They're also inexpensive and offer native IPv6 even > with their vServers. > You can do almost anything with it as long as it's legal, they don't forbid > any services. > > Regards, > Thomas > > > On 10.05.2012 18:49, Todd Eddy wrote: >> I already deleted it but somewhere in this thread people asked about >> places that support IPv6. >> >> I got a dedicated server from kimsufi.ie (they have a bunch of various >> TLDs for different countries but .ie (ireland) is where you go if in US) >> that's fairly inexpensive. Downside for someone in US is the server is >> located in France. But it supports native IPv6. Only native IPv6 I've >> seen in states is on VPSs which shouldn't have ntpd running on them. >> They are working on getting a datacenter in canada running by end of the >> year. Hopefully they'll still have an inexpensive dedicated server. >> >> On 5/10/12 12:47 AM, Ask Bjørn Hansen wrote: >>> >>> On May 9, 2012, at 17:44, Chuck Swiger wrote: >>> >>>> Please don't add machines which are behind a VPN tunnel to the NTP pool. >>>> They will experience additional noisy delays as a consequence of the >>>> VPN crypto which make them undesirable as timeservers. >>> >>> Two reasons I don't think this is necessarily a "hard rule": >>> >>> 1) The people who'll read a rule like that (or this list) are the people >>> most likely to take care in maintaining their NTP server, understand how >>> the pool system works etc. In other words, the people most likely to >>> follow a rule like that are not the ones who need to. >>> >>> 2) There are many many other reasons a server is undesirable as a >>> timeserver. I think it's best if we just stick to what we can measure with >>> automated monitoring. The one big exception is longevity of the service; >>> but I haven't thought of any way to predict or estimate this in advance >>> based on the information I have. >>> >>> >>> Ask >>> _______________________________________________ >>> pool mailing list >>> [email protected] >>> http://lists.ntp.org/listinfo/pool >>> >> >> >> >> _______________________________________________ >> pool mailing list >> [email protected] >> http://lists.ntp.org/listinfo/pool > _______________________________________________ > pool mailing list > [email protected] > http://lists.ntp.org/listinfo/pool
_______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
