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/address-policy-wg@ripe.net/
[address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)
- Previous message (by thread): [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sander Steffann
sander at steffann.nl
Sat Oct 22 18:39:00 CEST 2016
Hello Kai, > Sander, thanks for the historical context. > > It explains this statement from the proposal: »Today, organisation > networks usually include some kind of guest networks, (public) WIFI > hotspots in their offices, PTP-VPN links to customers’ sites, or > anything similar where devices of non-members of the organisation > would get assigned an IP out of the organisation’s prefix. Strictly > following the current RIPE policy regarding eligibility for IPv6 PI > space, organisations aren't allowed to be provided with PI space when > this is the case.« > > But there's nothing about that in ripe-655:»To qualify for IPv6 PI > address space, an organisation must meet the requirements of the > policies described in the RIPE NCC document entitled “Contractual > Requirements for Provider Independent Resources Holders in the RIPE > NCC Service Region” [reference goes to ripe-637 as of this writing].« > > Thus, there seems to be a policy, and an interpretation of that > policy, the later hidden in some slides? > > Now I do agree that the policy needs fixing, as it neither refers nor > at least mentions these »interpretations«. By policy's text, if you > sign the Independent Assignment Request and Maintenance Agreement with > a sponsoring LIR, you are qualified to receive IPv6 PI space, no? Yes, but the RIPE NCC checks your intended usage to confirm that it doesn't conflict with the policy. > BUT: how would the simple addition of »[w]ithin the context of these > policies, a sub-assignment is an assignment of a length of /64 or > shorter« will solve the issue that mentioning WiFi in the PI request > leads to it's refusal? (Note that »no WiFi« is not even present on > above's list.) There are dozens (maybe hundreds) of ways in which to use address space. Those examples aren't meant to be exclusive. Now, the problem is that we never properly defined what a sub-assignment in this context is. Just based on the language, every case where I tell you to use an address is an assignment. If I were to give you a bit of paper that says "you can use 2001:db8::1" then that is an assignment. I just assigned 2001:db8::1 to you. (Yes, we could get into the discussion that SLAAC isn't technically an assignment in this context but stateful DHCPv6 is, but let's not go there). Basically, under the current policy, based on the English language, letting any 3rd party use your IPv6 PI address space is a violation of the policy. > If above's »interpretation« is still the current one, it misses WiFi, > so that should not have led to refusal of PI assignments. If not, where > is the current one and how does the APWG influence it – and how does > the general public, e. g. an End User looking for PI space to IPv6- > number his or her gear once-and-for-all, learn about it? That were some examples, not a complete list. There is no such list. And 3rd party usage of IPv6 PI addresses is currently not allowed. What this policy tries to define is what sub-assignment, and define it as a /64 or more. So letting 3rd parties connect to your WiFi (which will assign them a couple of addresses) is fine, as is letting someone host a server on your network. But you're not allowed to give them their own /64 or more. If you do that then (under the proposed policy text) you are sub-assigning, which isn't allowed. Basically, what is proposed is: assigning separate addresses is fine, whole subnets is not. One of the things I would like to see discussed here is whether the current text is doing what it is supposed to. Is putting a limit at /64 a good criterium? I could comments like "this encourages people to make non-/64 subnets" etc. On the other hand, say we would instead write in the policy that assigning subnets to 3rd parties isn't allowed no matter which size, would that make /127 point-to-point connections impossible? Speaking as a chair: this issue has been around for a long time, and it keeps coming up. Without us (this WG) giving extra guidance to the RIPE NCC their interpretation of what we mean by "sub-assignment" can only be based on the English language, where assignment without any further qualification/quantification means *any* assignment, even if it's just a single address. So I would like to properly define in policy what we as a working group would like to happen. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: </ripe/mail/archives/address-policy-wg/attachments/20161022/2c10a197/attachment.sig>
- Previous message (by thread): [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]