[address-policy-wg] IPv6 PI assignment policy

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.