Anno domini 2015 Sascha Luck [ml] scripsit:
On Fri, Jun 19, 2015 at 09:52:10PM +0200, Ond?ej Caletka wrote:
I don't think it's a good idea. There is a reason why the usage of PI addresses is restricted. I think your proposal would lead to a situation where everybody uses PI addresses just-in-case even if they don't really need them, thus flodding the global routing table.
You might as well get used to the idea. If seen as a loose federation of independent "network clouds" (as I understand the Freifunk idea, correct me if I'm wrong), this offers a first glimpse into how things will be if and when the "Internet of Things" becomes something more than vapourware. We might as well start thinking about how to solve the coming resource management issues.
When by »loose federation of independet "network clouds"« you see every Freifunk community as one or more clouds which are loosely federated by mail/IRC communicated admins, then I could agree :)
For the Freifunk people here, could you provide some detail on how this is solved for IPv4 at the moment?
There currently are some solutions used by the different communities: a) each "Gateway" (central node in the Batman mesh network) has it's own VPN uplink to $vpn_provider (for legal reasons, usually outsite .de (think: Störerhaftung)) with NAT44 on the gateway and usually on VPN provider site, too. a2) Some internal routing to some concentrator nodes, then VPN uplinks there + NAT(s). b) GRE uplinks to Freifunk Rheinland e.V. who - as becoming LIR a not long ago - own a /22 and delegate small prefixes to each community over GRE tunnels + NAT44 before the GRE uplinks. c) I know of a least one lucky community which got a /24 delegation sponsored from one friendly ISP in northern Germany - may he out himself as I guess he's on this list - so they can use direct peerings for v4, too. But as legacy IP already is depleted there's not much thought put into that area in general as there's not much which can be done about it if there's no solution c) available. Personally I don't worry about IPv4 (besides building some active-active NAT44 solution with option »b« right now, which is kind of PITA) and put more hope into IPv6 where a large enough prefix which we could announce directly would enormously improve our upstream situation. I hope I could shed some light on the topic. Best Max -- If it doesn't work, force it. If it breaks, it needed replacing anyway.