Hi Jordi,
well, doesn't say so in the subject line, and cannot be done anyway: there is
no difference between "to assign" and "to assign". 2.6 (was and) is a
definition valid for any IPv6 assignment, be it PI, IXP, Anycast, whatever.
So you're aiming at a definition like:
>
> 2.6. Assign
>
> To “assign” means to delegate address space to an ISP or End User for
> specific use within the Internet infrastructure they operate, if it's
> Provider Independent IPv6 adress space. In case it's not Provider Independent
> IPv6 address space, and not IPv6 adress space for authoritative TLD or ENUM
> Tier 0/1 DNS lookup services either, to “assign” means to delegate address
> space to an End User, of the LIR as an ISP or a of an subordinate ISP, for
> […]. If the IPv6 address space in question is for authoritative TLD or ENUM
> Tier 0/1 DNS lookup services, to “assign” means […].
IMO that's not going to fly.
Furthermore, what needs to be "clarified" about "Assignments […] are not to be
sub-assigned to other parties"? They. Are. Not. Any, ever. PIv6 even doubly not
(7.). How to put this more "clearly"?
From the text of ripe-707, there is a rather clear definition what "making an
assignment" is about (and what isn't) — if this is not how this working group
expects the RIPE NCC to understand the policy text, then, and only then, the
text needs to be modified. Currently I see no motion to lift the "no
sub-assignment, period" clause, though.
How the RIPE NCC understands the, now current, policy text has been pointed out
as part of 2016-04 [1] ("A. RIPE NCC's Understanding of the Proposed Policy").
That "understanding" to me is "good enough" with regard to what 2.6 currently
reads. Please re-read that clarification, it's important — obviously you
_still_ missed that there is no difference between PIv6 and non-PIv6 in terms
of (sub-) assignment. That suggests that, if you're an LIR, an ISP, or an End
User, you're probably not assigning/using assigned address space as per policy.
That said: what you are aiming at is *not* a "clarification" of what a (sub-)
assignment is (and any sub-assignment still is an assignment and therefore
falls under the definition per 2.6.).
You are looking for extending the allowed use-cases of PIv6. Please keep in
mind, though, that anything that could count as a sub-assingment would be still
be forbidden by the Contractual Requirements for Provider Independent Resource
Holders in the RIPE NCC Service Region [2], so the only way forward is to
extend the examples in the second paragraph of 2.6 — the one 2016-04 brought
us. But why do you want to extend the allowed use cases for PIv6? To me, the
general idea that PI space should be for End Users, and End Users only (be them
companies, ISPs, or simply people), for their own use, still makes sense, as
well as this rationale from [2]:
> Some ISPs prefer to receive Internet number resources as an End User rather
> than becoming an LIR even though they provide services to their own customers
> and therefore sub-assign address space assigned by the RIPE NCC. Such End
> User ISPs often receive several separate PI prefixes as this can be a cheaper
> alternative for them. Sub-assignment of PI address space in this manner is in
> contravention of the RIPE policies concerning direct resource assignment
> policies. It is also detrimental to aggregation of routing prefixes in the
> global routing tables.
And, with the … odd interpretation – letting friends & family access one's WiFi
via IPv6 constitutes the act of sub-assignment – out of the way, IPv6 is
properly usable again, PI or not.
Regards,
-kai
[1] https://www.ripe.net/participate/policies/proposals/2016-04
[2] http://www.ripe.net/ripe/docs/contract-req
Am 17.01.2019 um 21:22 schrieb JORDI PALET MARTINEZ:
>
> Hi Kai,
>
>
>
> Actually, yes and not.
>
>
>
> I’m talking about the clarification of 2.6 in the scope of 7 (PI) not in the
> scope of PA.
>
>
> Regards,
>
> Jordi
>
>
>
>
>
>
>
> *De: *address-policy-wg <[email protected]> en nombre de Kai
> 'wusel' Siering <[email protected]>
> *Organización: *Unseen University, Department of Magic Mails
> *Fecha: *jueves, 17 de enero de 2019, 20:58
> *Para: *<[email protected]>
> *Asunto: *Re: [address-policy-wg] suggestions from the list about IPv6
> sub-assignment clarification
>
>
>
> Hi Jordi,
>
> you're mixing things up. This is not about 2016-04, which was approved long
> time ago. This is about ripe-707 [1], titled "IPv6 Address Allocation and
> Assignment Policy" — the current policy in question you want to be modified.
>
> Regards,
> -kai
>
>
> [1] https://www.ripe.net/publications/docs/ripe-707#assign
>
> Am 17.01.2019 um 20:34 schrieb JORDI PALET MARTINEZ:
>
> Hi Kai,
>
>
>
> You’re missing that 2016-04 is for the clarification of IPv6 PI, not PA.
>
>
>
> https://www.ripe.net/participate/policies/proposals/2016-04
>
>
> Regards,
>
> Jordi
>
>
>
>
>
>
>
> *De: *address-policy-wg <[email protected]>
> <mailto:[email protected]> en nombre de Kai 'wusel' Siering
> <[email protected]> <mailto:[email protected]>
> *Organización: *Unseen University, Department of Magic Mails
> *Fecha: *jueves, 17 de enero de 2019, 20:16
> *Para: *<[email protected]> <mailto:[email protected]>
> *Asunto: *Re: [address-policy-wg] suggestions from the list about IPv6
> sub-assignment clarification
>
>
>
> On 17.01.2019 15:37, JORDI PALET MARTINEZ via address-policy-wg wrote:
>
> We need to consider as well, as I depicted already before, that if
> you have a physical sever, you probably need also multiple addresses for that
> server, that's why, I think the policy should allow that (this is clearly now
> allowed now).
>
>
> Let's consult ripe-707:
>
>
>
> 2.6. Assign
>
> To “assign” means to delegate address space to an ISP or End User for
> specific use within the Internet infrastructure they operate. Assignments
> must only be made for specific purposes documented by specific organisations
> and are not to be sub-assigned to other parties.
>
> Providing another entity with separate addresses (not prefixes) from
> a subnet used on a link operated by the assignment holder is not considered a
> sub-assignment. This includes for example letting visitors connect to the
> assignment holder's network, connecting a server or appliance to an
> assignment holder's network and setting up point-to-point links with 3rd
> parties.
>
>
> 2.9. End Site
>
> An End Site is defined as an End User (subscriber) who has a business
> or legal relationship (same or associated entities) with a service provider
> that involves:
>
> · that service provider assigning address space to the End
> User
>
> · that service provider providing transit service for the End
> User to other sites
>
> · that service provider carrying the End User's traffic
>
> · that service provider advertising an aggregate prefix route
> that contains the End User's assignment
>
>
> By these definitions, only an IR ("2.1. Internet Registry (IR)") can
> "assign" allocated address space to non-IRs, i. e. ISPs or End Users, in the
> context of ripe-707.
> The term "ISP" is not wll defined within ripe-707 except for "LIRs are
> generally ISPs whose customers are primarily End Users and possibly other
> ISPs" in "2.4. Local Internet Registry (LIR)". The graph in "2. Definitions"
> suggests that ISPs are the entities that are actually creating the Internet,
> whereas (L)IRs are involved in distributing IP space only. Since, following
> 2.6., only an (I)SP _that also is an (L)IR_ could, acting in it's (L)IR role,
> "assign" address space, 2.9. should therefore receive a friendly "s/service
> provider/ISP/g" and have the first bullet point removed.
>
> On the other hand, 2.6. in it's current form – except for the "separate
> addresses (not prefixes)" issue, as any singke address IS technically also a
> /128 prefix – seems rather clear to me: if it's for the documented "specific
> use within the Internet infrastructure they operate", it's fine. Otherwise, a
> separate assignment is needed for either a new specific use _or a different
> End User_, so the ISP or End User (or the ISP for it's End User) will have to
> request that from an (L)IR (which it may be itself, if the ISP or End User is
> an LIR as well).
>
> Thus, if you need "multiple addresses" for your "physical server" and you
> received an assignment for your infrastructure including your server(s), I
> cannot see a conflict with ripe-707. If you want to add a dedicated server
> for a customer of yours, I'd expect you to get a new (non-PI) prefix (i. e.
> no less than a /64 as per 5.4.1.) for this different End User from your LIR
> of choice (or have that End User apply for a /48 PIv6 via your cooperative
> LIR).
>
> Regards,
> -kai
>
>
>
> **********************************************
> 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.
>
>
>
>
> **********************************************
> 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.
>
