Re: [address-policy-wg] IPv6 PI assignment policy
Hello Ondřej, list, the Freifunk communities are not going to give /64 to end users. There will be one single IPv6 address leased to end users connecting to the wireless networks. In Regards to the alliance out of some freifunk communities to obtain a PA-block: I don't think it makes any difference if there are 8 more prefixes /32 (from PA) or /48 (from PI) in the DFZ. Count of prefixes in the DFZ would be the same for both scenarios. Since no Freifunk communities has the need for a /32 prefix that would be a waste of addresses. Besides the costs of a LIR membership won't be easy to afford event not for 8 communities. @Sascha Luck: I think the policy should reflect that as it does for IPv4. Speaking in IPv4 this problem would not have occoured: IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. That problem has already been identified. (page 8) https://ripe69.ripe.net/presentations/72-APWG_RS_Feedback_Final.pdf Thanks, Thomas Am 19.06.2015 21:52, schrieb Ondřej Caletka: Dne 19.6.2015 v 13:56 Thomas Drewermann napsal(a): Dear colleagues, we recently requested an IPv6 assingment on behalf of one Freifunk Community in germany. They wanted to be indipendent from us and to take routing decisions on their own. As they are a freifunk community some of the PI assigment would be used to lease addresses to clients/users. According to NCC the policy currently doesn't permit usage of PI space. Hello Thomas, list, I'm not sure what networks typically a freifunk community network oparates. But if it can be compared to a very small ISP with tens to hundreds customers, than the PI assignment is not an option due to its fixed size of /48 which is simply not enough. You are not going to give a single /64 to customer, are you? On the other hand, if the freifunk only operates a few hot spots, comparable to some Wi-Fi service in a restaurant, etc. then all addresses can be in my opinion counted as a part of organisation infrastructure so the PI rules would not be violated. Small Hotspot providers and especially Freifunk communities typically can not afford a LIR Membership to be independent. In my opinion the current policy makes it hard to adopt IPv6 in such cases. Everybody would like to be independent to have some back-up scenario if something happen to their main uplink ISP. However, every new PI assignment have a permanent negative impact on the global routing table. I therefore think it is reasonable to have some limit for obtaining independent resources such as the RIPE NCC membership fees. What if the freifunk communities formed an alliance and become a LIR as a part of the alliance? It would lower the costs of becoming a LIR and at the same time allow communities to get enough independent IPv6 addreses that could be assigned to customers. I'd like to propose a change of the policy to allow PI addresses to be used for clients which don't belong the assigment-holder. This clients are connecting to networks which use address space of the holders PI assignment e.g. via wifi. 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. Best regards, Ondřej Caletka CESNET The difference between an assignment is that there is a single address provided to walk in wifi users rather than a whole subnet delegated for usage by the connecting client/user/customer. How do you think about that situation? What would be your thoughts on such a proposal? Regards Thomas Drewermann Freifunk Rheinland e.V.
Re: [address-policy-wg] IPv6 PI assignment policy
Hi Gert, So what's the user to do with this single address, and his network behind his router? User IPv6 NAT/Masquerading? I strongly encourage you to re-think this approach. [..] There won't be user's/customer's networks behind. All routers are part of the Freifunk infrastructure. All users will be on temporary basis like a guest network. Form them there will be no use for more than a single address. We are not going to use IPv6 NAT/Masquerading neither are we encouraging anyone to do so. @Sascha Luck: I think the policy should reflect that as it does for IPv4. Speaking in IPv4 this problem would not have occoured: IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. That problem has already been identified. (page 8) https://ripe69.ripe.net/presentations/72-APWG_RS_Feedback_Final.pdf Yes, we're aware of that, but this is the old a user only needs to have a single IP address, and can use NAT world. I think a device like a user's cell phone or laptop connecting doesn't need more the a single address. And everyone needing a subnet must operate a Freifunk router on his/her own. This router will be then part of the Freifunk community's infrastructure. So he/she operating a part of the infrastructure won't be considered a user. So there will be no problem in usage of the PI space except a guest user connecting temporarily. Because their devices won't be considered as part of the Freifunk communities infrastructure. Since we do not want to encourage this model for IPv6, nobody has ever brought forward a proposal to allow this approach for IPv6 PI. Will it be legimate to use adresses out of an PI assignment to lease them to users connecting temporarily? Besides the Freifunk use case there are some company's guest networks which have the same need. I don't think that the policy contains a statement about that. What do you think? (Now, I have no good answer what the Freifunk community *should* do. I can understand that you're indeed set up quite differently than a traditional ISP - OTOH, you're not the only one who runs a network on a non-commercial basis and needs IPv6 addresses. So using PA space from a friendly ISP in the neighbourhood - like, a /40 or even a /32 - might be a workable solution... yes, renumbering will be nearly impossible, but right now the RIPE model doesn't really permit free rides I want my own addreses, I want to run something that is similar to an ISP business, I want a slot in the global routing system, but I am not going to pay for it. We might want to change our member structure to accomodate non-commercial LIRs - but that's a topic for the AGM to decide...) The Freifunk community I requested the PI space for doesn't demand a free ride. I tought that PI AS/space is the legitimate way for small orgs to get a slot in the global routing system. Isn't that the case? The key difference between Freifunk and ISP business is that there is no service providing to anyone except temporary wireless users. Everyone who wants more than just to use the network temporarily must operate his/her own router and get part of the Freifunk community's infrastructure. The Freifunk communitiy is no instituation you can order a network service from. That's why there are no assignments of /64 to users. Gert Doering -- APWG chair Thanks, Thomas
[address-policy-wg] IPv6 PI assignment policy
Dear colleagues, we recently requested an IPv6 assingment on behalf of one Freifunk Community in germany. They wanted to be indipendent from us and to take routing decisions on their own. As they are a freifunk community some of the PI assigment would be used to lease addresses to clients/users. According to NCC the policy currently doesn't permit usage of PI space. Small Hotspot providers and especially Freifunk communities typically can not afford a LIR Membership to be independent. In my opinion the current policy makes it hard to adopt IPv6 in such cases. I'd like to propose a change of the policy to allow PI addresses to be used for clients which don't belong the assigment-holder. This clients are connecting to networks which use address space of the holders PI assignment e.g. via wifi. The difference between an assignment is that there is a single address provided to walk in wifi users rather than a whole subnet delegated for usage by the connecting client/user/customer. How do you think about that situation? What would be your thoughts on such a proposal? Regards Thomas Drewermann Freifunk Rheinland e.V.
Re: [address-policy-wg] IPv6 PI assignment policy
Hi Vladimir, in that manner they would not be independent from us as organization. If anything happens to us they would lose their subnet which has been allocated by us. I forgot one tought in my first mail. To be particular about the policy in my opinion guest networks provided by PI assigment holders e.g. companies aren't legitimate use either. Because addresses are leased to users/devices which don't belong the company holding the PI assignment. That addresses could be treated as assignments to third parties as well. Regards Thomas Am 19.06.2015 14:24, schrieb Vladimir Andreev: One fix: Not inetnum and route but inet6num and route6. 19.06.2015, 15:23, Vladimir Andreev vladi...@quick-soft.net: Another way: 1) Create inetnum with type ALLOCATED-BY-LIR inside of inetnum allocated by RIPE NCC to LIR; 2) Create route object with the same IP prefix as in step 1 and desired AS; 3) Announce your prefix; Also you may need to create at least one ASSIGNED inetnum inside ALLOCATED-BY-LIR inetnum. 19.06.2015, 15:15, Christopher Kunz chrisl...@de-punkt.de: Am 19.06.15 um 14:06 schrieb Vladimir Andreev: Hello! Why wouldn't they become a LIR? Small Hotspot providers and especially Freifunk communities typically can not afford a LIR Membership to be independent. In my opinion the current policy makes it hard to adopt IPv6 in such cases. As the OP wrote: It's too expensive for a non-profit communal organisation (typically made up of 3-10 enthusiastic community members without a real budget) to become a LIR just for the purpose of connecting one (!) city's Wifi to the world. --ck -- With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 -- With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503
