This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification
- Previous message (by thread): [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification
- Next message (by thread): [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jetten Raymond
raymond.jetten at elisa.fi
Thu Jan 17 14:03:27 CET 2019
Hello All, I have a maybe very strange opinion on this, so i'll share it with you. I agree with Jordi that the current situation is confusing and could be clearer... IPv6 PI should be used as very originally was intended, and it should not be subnetted or subdelegations should be made of it to other instances than the obtainer at all. Before you turn on the grill, what should be changed or made allowed or understood as intention, compared to the very original intention of PI IPv6 is that the temporary use as in f.ex your guest wlan, (the enduser will not get these ip:s with him/her when leaving the building, it’s a WLAN infrastructure that can be used as a "client" in this case even temporary). In a DC, as long as the infra and servers are used or more precisely accessed by clients, they also do not get the ip:s assigned, but use them to access these platforms. In these cases the ip subnets belong to the provider, not to the customer. (VPN is a service right?) If a customer of a DC needs an assigned block for whatever reason, they can obtain a normal v6 block , or if PI v6 is needed, its still available, apply for a PI v6 subnet from Ripe. (or even become a member). I hope this helps Rgds, Ray -----Original Message----- From: address-policy-wg <address-policy-wg-bounces at ripe.net> On Behalf Of JORDI PALET MARTINEZ via address-policy-wg Sent: 17. tammikuuta 2019 14:13 To: address-policy-wg <address-policy-wg at ripe.net> Subject: [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification Hi all, As you know, I've been working on different versions of a clarification to 2016-04 (https://www.ripe.net/participate/policies/proposals/2016-04). This proposal allows a single IP to be sub-assigned, and the author explained (not just in the policy proposal text, but also in the justification and in different emails), that the case they have is to make sure that the policy allows it for: 1) Datacenter services. 2) Interconnections (VPN, PNI, p2p, etc.). 3) Guess visitors (employees, hotspot users, etc.). The policy text doesn't mention those examples, but the summary talks about them: "Intended use cases for IPv6 PI space in the spirit of this policy proposal are the use in (public) WIFI networks (like the WIFI at RIPE meetings), as transfer networks on PNIs or other PTP-links/VPNs to users or customers, or for housing/hosting for servers in data centres. The use of IPv6 PI space for DSL/cable/FFTH/etc. subscribers is explicitly not an intended use case for this policy proposal." On the other side, the impact analysis indicates: "It is the RIPE NCCs understanding that assignments as described above are dynamic in nature, either by varying the prefix or interface identifier (IID) over time. Any permanent and static assignments of a prefix would still be considered a sub-assignment as per clause 2.6, “Assign” of the IPv6 address allocation and assignment policy. Consequently the RIPE NCC will not provide IPv6 PI assignments for such deployment plans." I don't think this is very clear, because 1) DC addresses usually are static. 2) Interconnections usually are static (p2p links at least). On the other side, as explained in my previous versions, I think that it is a valid case (in a hotspot, DC, etc.), instead of providing a single address, provide a full prefix (for example /64), so the host can have Virtual Machines running on different addresses of the same prefix. So, in my understanding we really need to clarify this text and for that, we need to decide what we want to be allowed and what not. So my questions are: 1) Do we agree that only dynamic should be allowed, or static is also ok? 2) According to 1 above, should the DataCenter case be alllowed? Thanks! Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
- Previous message (by thread): [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification
- Next message (by thread): [address-policy-wg] suggestions from the list about IPv6 sub-assignment clarification
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]