New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
IPv6 allocations
A question to those into ARIN policy. What does ARIN say about allocating IPv6 to customers?
I see plenty of VPS provided with /64. I can't imagine why you'd ever need that many IPs, but reading this and this indicates that it is normal practice. these rfc docs refer to "end site", but never define that, so I'm wondering how it applies to hosting.
Is there a policy doc that specifically mentions IPv6 and hosting providers? That is, what is considered to be recommended practice for allocating to a dedicated server, a VPS, etc.
Is assigning less than a /64 to a VPS a bad idea? does it matter?
Comments
I don't think anyone needs the amount of IP addresses, but everyone in a /64 is treated as one network. Then google will lock you out because so many devices from that subnet use it (happens on almost every LET VPS I use as a proxy) and it appears to be similar with email servers, although I have no experience with it.
TL;DR: I don't need more than 5-20 IPv6s, as long as they are from a /64 that no one else uses.
I'd say its more about common sense
/64 = 18,446,744,073,709,551,616 IPs - why would anyone want that on a VPS? There is no good justification for it.
https://www.arin.net/policy/archive/ipv6_policy.html
>
http://bcop.nanog.org/index.php/IPv6_Subnetting
Are you saying that sharing one /64 between multiple VPS is a bad idea?
common sense seems to contradict the "give /64 to anything" policy. common sense says "a dozen IPs per VPS is plenty". policy says "give billions, just in case you need more".
currently I'm allocating /112 to a VPS, as virtualizor doesn't do less. seems sensible to me. am I wrong?
I would be mad if my mail was rejected because someone else on the same /64 sent spam so..
This. It's not your fault it's Googles
interesting point. didn't think about spam issues.
Yep. Unfortunately you always have to make it right for everyone when sending mail.
I would say thats a good policy. We give /112 with VPS too. Its a reasonable amount of IPs.
Spam should not be controlled by limiting IPs or having to cater for bad management. If you have a spammer, you should catch him/her in realtime before he/she has time to cause that level of damage.
Explain this to ColoCrossing. They re assign dirty IPs you got no choice
they're "working on it"
They're cleaning it up from what I heard, but it needs to include having responsible users on their space too.
Oh they are. But it still is there
coming back to my original question, is there's anything in policy that mentions hosting?
"site" could mean VPS, or server, rack, suite, DC. policy of /48 per end site could be considered to be end site == DC, but I doubt it.
You can swap them out for clean ones...
Back on topic It's easy (and hopefully even easier/cheaper soon) to get a /48 with a dedicated server, and even SolusVM supports giving /64 subnets so i don't see why not.
It comes down to one thing:
Is allocating 18,446,744,073,709,551,616 IPs to a 512MB VPS justifiable. Answer No. There is no good justification for it.
Is allocating 65,536 (/112) IPs to a 512MB VPS justifiable. Answer No. But /112 allows the last long-word in the IPv6 to be used, so its easy to read from a routing perspective and not dramatically wasteful compared to /64.
512MB RAM with 65,536 IPs applied to the network interface is very unlikely to actually happen. I'd say out of all the IPv6 we've issued less than 0.0000001 (random number - for illustration) is actually even setup.
If you think, /112, /64 or whatever is too much, what do you think about LIR allocations of size /32 to /29? (79,228,162,514,264,337,593,543,950,336 - 633,825,300,114,114,700,748,351,602,688 addresses)
I think it's more down to block lists and /64 treated as one person/website
It comes down to one thing (from RFC 5375 - IPv6 Unicast Address Assignment Considerations):
features of IPv6, including Neighbor Discovery (ND), Secure Neighbor
Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of
Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode
(PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6
Intermediation (SHIM6) [SHIM6], among others. A number of other
features currently in development, or being proposed, also rely on
/64 subnet prefixes.
If your hosting provider is allowing the IPs to be blacklisted then you should request new IPs or move provider. There are so many tools to detect spamming, DOS'ing in realtime these days that there is no excuse for IPs to be backlisted.
Proactive management of assigned IP space is critical otherwise you just end up in a mess like ColoCrossing did.
The first line of defense is the hosting provider and the second line is the datacentre operator. If both parties aggressively manage their space then blacklisting of IPs shouldn't be a daily problem.
RIPE default alloc = /29 (~520000 /48)
Customer default alloc = /48 (~65000 /64)
Customer end-user assignment = /64
IIRC you should allocate either a /64 per end user device (like a server) and a /48 per customer (where you get the /64s out of). Blacklists currently work on /64 (Spamhaus escalation = /48) level so assignments of /112, while looking nice and easily manageable, could cause issues for other services in the same /64.
I do not consider any ISP for service that assigns less than a /64.
presumably it's up to the hosting to interpret customer = VPS = /64
thanks for the comments
Since when is IPv6 about "number of IPs"? Get rid of old IPv4 perspective when you talk about IPv6. It's completely different addressing scheme.
Considering your point of view I suggest you to return whole /29 (or whatever subnet you have already) and keep just simple /48 as you're just wasting millions of IPs with no assigning them properly (or rather: not assigning them at all).
My regular LET copy/paste:
Talking about 18,446,744,073,709,551,616 or 65,536 IPv6 addresses make people look silly.
Definitely agree with @Spirit.
Have a look at this guide that is officially referred to by RIPE: http://www.ipv6forum.com/dl/presentations/IPv6-addressing-plan-howto.pdf
So /48 or /64, or in between. You'll still have plenty and everything will work as it should.
That's the RIPE point of view, and so /48 PI is assigned with no questions asked, and more require justification.
There is an abundance of IPs on v6, don't count beans and go with /64 since everyone that matters (mail, sites, etc.) considers /64 as one single subnet and acts accordingly.
It is your fault and not Google's. Google just implements IPv6 it's the way it's supposed to be implemented. The fact that many people (and worse: providers) don't seem to understand that is the reason there are so many issues.
Don't tell me about google (or rather gmail) properly implementing ipv6. They suck. They were the reason why at some point i made our mail servers work on ipv4 only and not try to send any emails over ipv6.
In what way? Yeah at some point they mandated rDNS to be defined on IPv6. And -- shock and horror! -- turns out many people were lazy and didn't bother up until then, even though iirc by RFCs you have to, for a mail server. Guess some still sore about their mail bouncing due to their own sloppiness with IPv6 rDNS.
No. It was bouncing even with properly setup rdns for ipv6.
I agree with @rds100. There was a period I've done same, but those issues are long gone
.