[AusNOG] UK server hosting

Thu May 2 11:23:06 EST 2013

On the topic, the default APNIC allocation for a non-ISP is a /48. That’s just an insane amount of IP’s but again, its all about simplifying internal and external routing tables.

I would agree with that about the compromised host as well, if you know its compromised, it should be easy to find.

Thanks,
Ayden Beeson

From: ausnog-bounces at lists.ausnog.net [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Peter Tiggerdine
Sent: Thursday, 2 May 2013 11:17 AM
To: Sean K. Finn
Cc: ausnog at lists.ausnog.net
Subject: Re: [AusNOG] UK server hosting

From the Ipv6 world, the reason for allocated /64 or greater to customers is to keep the size of the routing table to a minimum

RFC 6177 seems provide a much more open guidance and appears to distance itself from the previously championed reasons.

The question is; is there a reason we need to allocate smaller than a /64 when the amount of subnets in (still the default allocation from APNIC for ISP?) /32 boggles the minds. Would also mean a greater pain for IPAM's. It's possible hosting requirements differ from DC, LAN/WAN and carriage..

Not sure I subscribed to the problem of finding which host in 4billion is compromised. I would think and IPS/IDS is going to give you an exact IP address and DNS or rDNS should provide which vhost if might be (if you happen to still use this method in apache). Maybe more information could help shed light on the operational issue..

Remember ipv6 was designed to only see lest that 1% (i think) of addresses used.

Regarding ipv4, this could be a great reason to look at ipv6 for connectivity and ipv4 on NAT64/DNS64.. Feel free to dis-agree. I'm a firm believer in single stack where possible and utilising ipv4 on LB with Nat64 and DNS64. I am aware there are caveats.

On Thu, May 2, 2013 at 10:44 AM, Sean K. Finn <sean.finn at ozservers.com.au<mailto:sean.finn at ozservers.com.au>> wrote:
/31’s *ARE* weird in server world. I’m sure not in ISP world, but in server world they are damn weird. You’ve got one IP for your server, an IP for your gateway, and no broadcast or network address.

Sure it wastes the two outside IP’s.

If there is a better way to assign a single IP to a server than by assigning a single gateway address, a single server IP address, and burning the other two IP’s, and giving the customer their own VLAN, I’d like to know what it is, and how much easier it is to setup.

Do we need to get clients to install a PPPoE Client on their server to get their IP from their /31?

My first question is, genuinely, is there a way to achieve this (using a /31 for servers) to help me conserve IP space?

For the record, I need to burn 5 IP’s for most customers, leaving three usable:
The first IP for physical Router one,
The second IP for physical Router two,
The third IP for the VRRP or HSRP Virtual Router floating IP, which is used as the actual gateway,
Another two burnt for Network address, and Broadcast Address, leaving three usable IP’s from a starting pool of a /29

As for IPv6 , school’s still out on assigning /64’s to customers.

I’ve got carrier links with IPv6 and for each one, by carriers, I’m assigned a /126 (not a /127), which gives them one IPv6-ip, and me one IPv6-ip.  I don’t need a whole /64 to connect to points.

If I’m providing a server to a customer with, lets say, 32 IP’s for hosting, or whatever their requirement, do they really need more than a corresponding 32 IPv6 IP’s to achieve the same goal?

Do I need to assign them four billion IP’s just because I can? Or FourBillion Squared?

My easiest solution is, if I provide a customer with a /24, then I’ll provide them with a matching /120 of address space, at least for the time being.

It keeps the usage simple to begin with, and also aids in indentifying single hosted compromised sites.

(Do I REALLY want to figure out which of the four billion IP’s a client is using to host their compromised site on?)

If you want a /64, sure, why not, go nuts, do your own thing with it, but it *IS* overkill for non nerdy customers who just-want-their-bloody-hosting-to-work.

Any and all feedback, and any opinions that counter mine are not only welcome, but encouraged, I want to hear what other people think about IP assignements, as I can’t live in a knowledge bubble. (And I’m sure any spectators don’t want to either).

Sean.

From: ausnog-bounces at lists.ausnog.ne<mailto:ausnog-bounces at lists.ausnog.ne> t [mailto:ausnog-bounces at lists.ausnog.net<mailto:ausnog-bounces at lists.ausnog.net>] On Behalf Of Tom Storey
Sent: Thursday, May 02, 2013 12:20 AM
To: august forsakov
Cc: ausnog at lists.ausnog.net<mailto:ausnog at lists.ausnog.net>
Subject: Re: [AusNOG] UK server hosting

You will get a lot of responses from the UKnof list, competition is quite healthy it seems. I did this myself mid last year and ended up with 3-4 providers to choose from.

I have one criticism for Othello. They thought /31's were wierd and that they had "a better system using /30's" and couldnt understand why someone would want a /64 of IPv6 because it was "a *VERY* large block for IPv6" to quote verbatim ... Basically their sales guy gave me the wrong impression about them.

On the other hand I had a very good conversation with Xifos, they were most accommodating to what I was looking for, so I give them two thumbs up. They are based in Reading, so a bit west of London, but that could also be a good thing if you've ever visited here. :-)

On 29 April 2013 09:32, Mark Prior <mrp at mrp.net<mailto:mrp at mrp.net>> wrote:
On 29/04/13 3:44 PM, august forsakov wrote:
Looking for server hosting in the UK.
Needs to be hardware only.
We plan to install and manage several VMs to host some of our stuff over
there.

You might be better off sending the query to the UKNOF list uknof at lists.uknof.org.uk<mailto:uknof at lists.uknof.org.uk>

Mark.

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog

[cid:csu-logo18d7.bmp]<http://www.csu.edu.au/>

|   ALBURY-WODONGA   |   BATHURST   |   CANBERRA   |   DUBBO   |   GOULBURN   |   MELBOURNE   |   ONTARIO   |   ORANGE   |   PORT MACQUARIE   |   SYDNEY   |   WAGGA WAGGA   |

________________________________
LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia<http://www.csu.edu.au> The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT)). TEQSA Provider Number: PV12018
Charles Sturt University in Ontario<http://www.charlessturt.ca/> 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca<http://www.peqab.ca>

Consider the environment before printing this email.

Disclaimer added by CodeTwo Exchange Rules 2007
www.codetwo.com<http://www.codetwo.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20130502/158569d9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: csu-logo18d7.bmp
Type: image/bmp
Size: 37976 bytes
Desc: csu-logo18d7.bmp
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20130502/158569d9/attachment.bin>