Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Dear Sander and Jordi, On 2018-01-19 11:57:38 CET, Sander Steffann wrote: > Hi Jordi, > > > 1) Policy text say: "... separate addresses (not prefixes) ...". > > 2) Max proposal say: "... or anything alike where devices of non-members of > > the organisation would get assigned an IP out of the organisation’s prefix > > ..." > > 3) Max proposal say: "... Explicitly allowing another entity to be provided > > with addresses from a subnet ..." > > 4) Max proposal say: "... A subnet in the spirit of this policy is a prefix > > from the PI/PA assignment with a prefix length of /64 or longer ..." > > 5) Max proposal say: "... or for housing/hosting for servers in data > > centres ..." > > 6) IA say: "... There are cases where a /64 is needed per customer to > > provide a separate address ..." > > 7) IA say: "... 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 ..." > > 8) IA say: "... by using single IPv6 addresses for End User devices and > > services ..." > > > > [...] > > > > 5 seem to indicate that this is acceptable in data centres, but 7 says > > permanent and static ... I don't see how a data centre can do temporary > > addresses? > > Now that is indeed a contradiction that I agree with. Here the NCC's > interpretation is more strict than what the policy says, and that should be > corrected. Marco, can you look at this again from the NCC's perspective? > > Cheers, > Sander > I'm happy to provide some clarification here. If this policy change is accepted, it will be possible to connect a customer server to the IPv6 PI assignment holder's network, provided only a separate address is used. This is clearly specified in the proposed policy text. Our reference to the dynamic provision of a prefix was referring to configuration mechanisms that are mainly used to provide Internet access to customers. The RIPE NCC's approach aims to support the intent of the proposal to allow IPv6 PI assignments for use cases such as (public) Wi-Fi networks but to discourage the use of IPv6 PI for permanent broadband services. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Dear Max, On 2018-01-15 18:23:42 CET, Maximilian Wilhelm wrote: > As said before somewhere (I'm not sure wether on a RIPE meeting or > here on the list), the RS folks said, that they use the proposal text > as well as the summary/rationale as guidance what is allowed and what > isn't. > > Maybe Ingrid, Andrea, Marco, * from the NCC can comment on that? > Yes, this is correct. Whenever there is a question about the interpretation of RIPE Policies, we can refer to proposal summary as well to the impact analysis to ensure the correct understanding of the policy and its intent. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
This is what I read in the PDP: It gives time to the community after the relevant WG chair declares rough consensus at the end of the Review Phase so that suggestions for any final changes or objections to the proposal can be sent to the WG mailing list. At this stage, objections need to be justified just as in the other phases for them to be taken into account. I think text in the policy contradicting the goal of the policy and the Impact analysis is a very objective reason to do something about it. Saludos, Jordi -Mensaje original- De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Jim Reid <j...@rfc1035.com> Fecha: lunes, 15 de enero de 2018, 14:29 Para: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) > On 15 Jan 2018, at 13:21, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> wrote: > > Hi Marco, > > I feel then contradictory this: ... detailed nit-picking of policy proposal deleted ... Jordi, we're past the point where substantive discussion of 2016-04 takes place. That's supposed to stop once a proposal reaches Last Call. I quote from Section 3.2 of the PDP again: At these stages of the process – i.e. after the WG chair has declared initial consensus or the proposal is in Last Call – complaints should not be about the policy proposal itself unless there are exceptional extenuating circumstances. ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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.
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
> On 15 Jan 2018, at 13:21, JORDI PALET MARTINEZ via address-policy-wg >wrote: > > Hi Marco, > > I feel then contradictory this: ... detailed nit-picking of policy proposal deleted ... Jordi, we're past the point where substantive discussion of 2016-04 takes place. That's supposed to stop once a proposal reaches Last Call. I quote from Section 3.2 of the PDP again: At these stages of the process – i.e. after the WG chair has declared initial consensus or the proposal is in Last Call – complaints should not be about the policy proposal itself unless there are exceptional extenuating circumstances.
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi Marco, I feel then contradictory this: 2.6 change 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. Clearly say “not prefixes”. While, in the impact analysis: “If this proposal is accepted, it is the RIPE NCC’s understanding that for an IPv6 assignment, the provision of separate addresses to customers of the assignment holder will not be considered a sub-assignment. In IPv6 terms, a single address is a /128. There are cases where a /64 is needed per customer to provide a separate address, for instance by using dedicated (v)lans to connect Wifi customers or other configuration mechanisms discussed in the technical community. The RIPE NCC will consider such mechanisms as being in line with this policy and not a sub-assignment as long as the subnet size does not exceed a /64.” (by the way this mechanism is now RFC8273, so you could update the link to https://datatracker.ietf.org/doc/rfc8273/) I also don’t understand “either by varying the prefix or interface identifier (IID) over time”. While I agree on the first part, if you change the IID, you may be using it for privacy, but it may be also that the link is being used by a different hosts, or even mutiple hosts. This may mean a broadband customer with a /64 from an ISP that has only PI … I think this policy proposal is very harmful because it allows and even encourages, ISPs to just use PI and allocate customers with a single dynanic /128 or /64, which is terrible for IPv6 deployment. I believe this policy needs to: 1) Clearly allow /64 using RFC8273 2) Clearly disallow broadband services, unless is temporary “hotspots” connections (and similar cases, for example, BYOD in corporate networks, guest WiFi, etc.) 3) Clearly disallow a service of more than “few consecutive hours” (to avoid a company using PI to provide the service for employees or “guest” continuously) 4) I’m concerned also because I’m not sure if we want to allow using this policy for datacenters. Should datacenters be PA or PI? I tend to believe that they should be PA, may be NCC stats on this can help to clarify it. So, with the current text of this proposal I opposse to it, as it clearly has very important contradictions that need to be resolved before implementing it. Clearly I’m sure everybody will agree on working in improving it and resolving those, instead of requiring going to an appeal process. This is a suggestion for an alternative text: “Providing another entity with separate addresses (even /64 prefixes following RFC8273 or alternative technologies) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors and/or employees (BYOD) 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. Provision of broadband services or connectivity to customers in a non-temporary way (“not a guest or employee for a few consecutive hours”) is considered a sub-assignment.” Thoughs? Regards, Jordi -Mensaje original- De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Marco Schmidt <mschm...@ripe.net> Fecha: lunes, 15 de enero de 2018, 12:53 Para: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Dear Jordi, Thank you for your question. On 2018-01-15 11:21:10 CET, Jordi Palet Martinez wrote: > Furthermore, I will like a clarification from NCC about what I mention in the mike, I think is this comment: > > One of the opposing remark was that this would prevent "unique prefix > per host" style allocations, but that was addressed by Marco at the > APWG meeting already - the RS interpretation is "this would work". > My comment during the Address Policy WG session at RIPE 75 was referring to configuration mechanisms where a /64 is needed per customer to provide a separate address, for instance by using dedicated (V)LANs to connect WiFi customers. Such mechanisms will be considered in line with the policy. Section A of the impact analysis provides more details on our understanding for these cases. https://www.ripe.net/participate/policies/proposals/2016-04 I hope this clarifies. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum **
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Dear Jordi, Thank you for your question. On 2018-01-15 11:21:10 CET, Jordi Palet Martinez wrote: > Furthermore, I will like a clarification from NCC about what I mention in the > mike, I think is this comment: > > One of the opposing remark was that this would prevent "unique prefix > per host" style allocations, but that was addressed by Marco at the > APWG meeting already - the RS interpretation is "this would work". > My comment during the Address Policy WG session at RIPE 75 was referring to configuration mechanisms where a /64 is needed per customer to provide a separate address, for instance by using dedicated (V)LANs to connect WiFi customers. Such mechanisms will be considered in line with the policy. Section A of the impact analysis provides more details on our understanding for these cases. https://www.ripe.net/participate/policies/proposals/2016-04 I hope this clarifies. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Ondřej Caletka wrote: > The only difference is that with PI, the it is the RIPE NCC evaluating > the rules, which seem to be too strict in considering what should count > as sub-assignment. But if we try to fix this, let's keep the fix working > both for PI and PA addresses. Just because the problem is not visible in > PA world does not mean it does not exist there. I see what you mean here, but this is something that has been almost universally ignored for PA assignments since forever. Nick
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Dne 8.11.2017 v 16:54 Nick Hilliard napsal(a): > it's removing the block on sub-assigning to > other parties, which is the thing that distinguishes PI from PA. Nick, I think this is a wrong interpretation of the problem. There's actually no distinction between PI and PA, the rule is that "sub-assignments are forbidden" regardless of PI/PA nature of the addresses. The only difference is that with PI, the it is the RIPE NCC evaluating the rules, which seem to be too strict in considering what should count as sub-assignment. But if we try to fix this, let's keep the fix working both for PI and PA addresses. Just because the problem is not visible in PA world does not mean it does not exist there. I elaborated more on the PA side of the problem here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-November/011943.html -- Ondřej Caletka smime.p7s Description: Elektronicky podpis S/MIME
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
* Gert Doering[2017-11-08 11:43]: > Hi, > > On Wed, Nov 08, 2017 at 11:20:34AM +0100, JORDI PALET MARTINEZ wrote: > > Ok, here is it then. Hopefully we have a lot of fun and good noise ;-) > > (that's music?) > > Thanks. > > So, basically, we have two possible approaches here: > > proposed by Max (active proposal): > keep the IPv6 PI policy as somewhat restrictive, trying to find wording > that permits "some generally accepted" use-cases where other people's > devices can get numbers from someone's IPv6 PI block > > or, > > proposed by Jordi (new direction): > completely remove the restrictions on "letting other people use parts > of someone's IPv6 PI block" I support 2016-04. It solves real problems that people have right now and is easy to understand. By all means try to succeed with the masterstroke of unifying PI and PA but I don't think this should block the current proposal as it probably will require "quite a bit" of discussions and revisions. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant signature.asc Description: PGP signature
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi, On Wed, Nov 08, 2017 at 05:48:42PM +0100, Maximilian Wilhelm wrote: > [...] > > I feel that the current version is solving partially Max case, but even in > > his case, if he decides to provide /64 for each hot-spot customer, this > > proposal will not work. > > Actually the NCC IA interpretation is rather clear on this one - as > Marco (IIRC) confirmed while the WG session. /64 assignments to hosts > aren't a problem with the current policy text / interpretation. Precision of language: "... with the proposed new policy text". (Sorry to be nit-picking here) gert -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
On 08.11.2017 11:20, JORDI PALET MARTINEZ wrote: > Ok, here is it then. Hopefully we have a lot of fun and good noise ;-) > (that's music?) > > The main idea is to allow what Max (and many other people) needs in PI, but > not having restrictions. > > For that, what I’m proposing is: > > 1) Change the actual definition of Assign in 2.6, to: > 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, with the exception of > Provider Independent (PI). To me, this wording makes things even worse. This makes PIv6 more adorable (less restricted) and will lead to more confusion instead of less. > 2) Remove last paragraph in 7. IPv6 Provider Independent (PI) Assignments > So, REMOVE: The PI assignment cannot be further assigned to other > organisations. I'm happy with the "no subassignent" restriction (as in: you cannot enter a bigger prefix in the RIPE DB, even as an LIR), I challenge NCC's interpretation of allowing third party users use my PI space temporary being a sub-assignment (guest WiFi/Freifunk case). > Rationale: > > a. Arguments Supporting the Proposal > This proposal will avoid the situations of breaking existing policy when a > network using PI is using the addressing space for point-to-point links or in > cases such as providing connectivity to employee or visitor devices (BYOD), > hot-spots, and similar situations. > At this way, regardless of if a single /128 or /64 is sub-assigned, and > independently of what technology is used for that (SLAAC, DHCPv6, DHCPv6-PD), > the restriction is no longer an issue. My employees are part of my organisation, no issue there. Visitors are what is objected by the NCC, as they are not part of the organisation that holds the PI assignment. But then the RIPE NCC is in breach with it's own interpretation when using their PI space on a RIPE Meeting's public network (wired & wireless): not every WiFi user at a RIPE Meeting is an employee of the RIPE NCC. So, next time we'll see the RIPE NCC requesting a temporary PA (v4 and v6) from the providing ISP for the Meeting's network? Similarily, as my family isn't me, I may not allow them to use PI space assigned to me? But then, what's PI good for anyway? Any service that's setup/operated/funded by the assignee (the holder of (PI) space) should be considered proper use of these Internet resources, as far as the IR is concerned. > b. Arguments Opposing the Proposal > It can be argued that this proposal could increase the number of PI request > to RIPE NCC. > > Mitigation/counter-argument: This is not an issue and should not be > considered as a “bad-effect”. > > The resulting policy could be used to circumvent the allocation policy, > avoiding creating a LIR. > > Mitigation/counter-argument: This seems not to have sense as there must be a > justification process anyway, and because the starting point is /48, an ISP > willing to connect customers, will really want to be an LIR. Furthermore, if > we want to be restrictive on this, we could add a limitation that the maximum > sub-assignment can be /64. So I need a /48 per WiFi I use (as each requires an /64 and two "sub-assignments" therefore would exceed the limit)? Does not look like it solves any issue ;) Still: I don't think ripe-684 needs an update. At fault is the RIPE NCC's, highly inconsistent, interpretation of the term "sub-assignment". ripe-684's definition of "assign" states (in 2.6): "Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties". If a /128 for a device that doesn't belong to the organisation holding a IPv6 assigment is a "sub-assignment", there is *no* way for *any* organisation to (in accordance of RIPE NCC's interpretation) provide externals with public IPv6 addresses. By any means. Regardless if the organisation is an IR or not. (Well, an IR could formally "assign" address space from their allocated, unassigned pool, if the End User comes with "Internet infrastructure they operate"; different story.) I somewhat doubt that RIPE NCC teaches this interpretation to (old and) new LIRs for evaluating PA requests. But then there is no justification to interpret the definition of "assign" in 2.6 differently for PI. As I don't think the intent of ripe-684 was to prevent the use of IPv6 on guest or even public WiFi, in coworking spaces, hotels or at meetings, the sane thing to do is to abolish this interpretation of an /128 being a "sub-assignment" within the RIPE NCC. It's nowhere in the policy text; on the contrary: This "/128 is a sub-assignment" interpretation even contradicts ripe-684. Quoting 5.4.1. ("Assignment address space size"): "End Users are assigned an End Site assignment
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Anno domini 2017 JORDI PALET MARTINEZ scripsit: Hi, > Ok, here is it then. Hopefully we have a lot of fun and good noise ;-) > (that's music?) > The main idea is to allow what Max (and many other people) needs in PI, but > not having restrictions. > > For that, what I’m proposing is: > > 1) Change the actual definition of Assign in 2.6, to: > 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, with the exception of > Provider Independent (PI). > > 2) Remove last paragraph in 7. IPv6 Provider Independent (PI) Assignments > So, REMOVE: The PI assignment cannot be further assigned to other > organisations. > > Rationale: > > a. Arguments Supporting the Proposal > This proposal will avoid the situations of breaking existing policy when a > network using PI is using the addressing space for point-to-point links or in > cases such as providing connectivity to employee or visitor devices (BYOD), > hot-spots, and similar situations. > At this way, regardless of if a single /128 or /64 is sub-assigned, and > independently of what technology is used for that (SLAAC, DHCPv6, DHCPv6-PD), > the restriction is no longer an issue. > > b. Arguments Opposing the Proposal > It can be argued that this proposal could increase the number of PI request > to RIPE NCC. > > Mitigation/counter-argument: This is not an issue and should not be > considered as a “bad-effect”. > > The resulting policy could be used to circumvent the allocation policy, > avoiding creating a LIR. > > Mitigation/counter-argument: This seems not to have sense as there must be a > justification process anyway, and because the starting point is /48, an ISP > willing to connect customers, will really want to be an LIR. Furthermore, if > we want to be restrictive on this, we could add a limitation that the maximum > sub-assignment can be /64. > Thoughts? I like the idee, but I'm totally with Nick on this one: It's a much larger change - which I support - but don't think, that we can get this implemented into policy in the near future. So I propose to *now* implement my proposal with the smaller change and then get the bold move of lifting more restrictions or even lifting the distinction between PI/PA going. I think it's safe to predict that if we shift to your approach right now, we will still be discussing this on the next RIPE meeting, or even the one after that as the area of things touched by this change is considerably larger, as pointed out by others already. That way we solve the real time problem - which we all agree on, right? - right now and make PI great again, and then have time to make the world and even better place afterwards. :-) Best Max
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
On 08.11.2017 16:54, Nick Hilliard wrote: > JORDI PALET MARTINEZ wrote: >> I don’t think reaching consensus in the PI/PA change will be so easy >> in the “near future” (considering that it may require a long >> implementation time), and a middle way proposal looks feasible to >> me. > but it's not a middle way: it's removing the block on sub-assigning to > other parties, which is the thing that distinguishes PI from PA. It's not, as that isn't a distinction; sub-assigning is blocked in general. Quoting https://www.ripe.net/publications/docs/ripe-684#assign: > 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. Regards, -kai
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Anno domini 2017 JORDI PALET MARTINEZ scripsit: Hi Jordi, [...] > I feel that the current version is solving partially Max case, but even in > his case, if he decides to provide /64 for each hot-spot customer, this > proposal will not work. Actually the NCC IA interpretation is rather clear on this one - as Marco (IIRC) confirmed while the WG session. /64 assignments to hosts aren't a problem with the current policy text / interpretation. Best Max
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Erik Bais wrote: > I don’t think that the fear from past times is something that we > should keep in this discussion these days.. the issue isn't fear from past times: it's that PI & PA are ingrained pretty deeply in the RIPE NCC billing model and service expectation model, and some way would need to be found to square a number of circles in order to integrate the two flavours of integers. I'm not objecting to trying to get this done, btw, just saying that if we're going to do it, let's do it properly. Regarding 2016-04, it's clear that the current rules / rule interpretations are too limited and are causing problems in the real world, so the sensible thing to do would be to open up the usage terms so that third parties can use PI assignments, even if the addresses are not subassigned. This doesn't go as far as what Jordi is talking about and looks like a practicable middle ground to aim for. Nick
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi Gert, Nick & Jordi, I don’t think that the fear from past times is something that we should keep in this discussion these days.. If you have a look at which speed hosters / ISP are opening up new LIR’s for the /22 IPv4 … and are able to get their own v6 /29, just because they need the v4 anyway .… I have serious doubt if someone would even consider to get a ‘cheap’ /48 PI just to game the system. It would have my vote to remove as much of the IPv6 PI restrictions as possible, but keep the /48 PI limit without documentation … The goal of aggregation is noble for the DFZ, but if you have a look at the current v6 space and what people are de-aggregating their v6 prefixes into .. you would probably have to agree with me that this discussion doesn’t apply to the real world anymore. The discussion of financial cost for v6 space is nothing if you look at the cost for getting v4 .. and if someone wants to do the documentation for PI space .. rather than becoming a LIR.. where you can get a /29 without any questions or documentation .. Go for it .. If you have that amount of customers .. I think you would be an LIR already .. Just have a look how certain companies are doing more specific announcements of their /32 in /48’s .. or even smaller… If customers want to implement v6 .. using PI space for their internal infra .. or even host a server or 200 on that /48 .. let them have fun with it.. The reality is that is not where the pollution in the routing table will come from imho .. I do think that a proposal to change the PI v6 requirements should be a separate discussion and policy proposal. Regards, Erik Bais On 08/11/2017, 17:14, "address-policy-wg on behalf of Gert Doering"wrote: Hi, On Wed, Nov 08, 2017 at 03:54:42PM +, Nick Hilliard wrote: > JORDI PALET MARTINEZ wrote: > > I don???t think reaching consensus in the PI/PA change will be so easy > > in the ???near future??? (considering that it may require a long > > implementation time), and a middle way proposal looks feasible to > > me. > > but it's not a middle way: it's removing the block on sub-assigning to > other parties, which is the thing that distinguishes PI from PA. Which is one of the things. Other things are "how big will that bag of numbers be" and "what costs are attached to it". Especially the "how big will that bag of numbers be" will certainly be something we'll have to discuss next, shall we decide to open up PI for "more liberate use" (like, will "I want to assing a million /64 to DSL users" be a sufficient reason to get "larger than a /48"?). Consequences to all we do... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi, On Wed, Nov 08, 2017 at 05:16:32PM +0100, JORDI PALET MARTINEZ wrote: > That???s why I suggested that the limit can be only /64 if we want to have a > in PI at the time being. A /64 for what? per customer? So, what is the answer we give to the NCC when they come to us and say "so, this large Telco with 10 million customers has asked for a /40 PI, to give all their customers a /64"? Not that a /40 would really "lots of space", and it's one routing table slot either way, but we need to decide "is this something we consider 'acceptable use' or 'deny this request'". (I pretend to not have an opinion, so you, as the community, decide) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
That’s why I suggested that the limit can be only /64 if we want to have a in PI at the time being. Regards, Jordi -Mensaje original- De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Nick Hilliard <n...@foobar.org> Responder a: <n...@foobar.org> Fecha: miércoles, 8 de noviembre de 2017, 16:55 Para: <jordi.pa...@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) JORDI PALET MARTINEZ wrote: > I don’t think reaching consensus in the PI/PA change will be so easy > in the “near future” (considering that it may require a long > implementation time), and a middle way proposal looks feasible to > me. but it's not a middle way: it's removing the block on sub-assigning to other parties, which is the thing that distinguishes PI from PA. Nick ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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.
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi, On Wed, Nov 08, 2017 at 03:54:42PM +, Nick Hilliard wrote: > JORDI PALET MARTINEZ wrote: > > I don???t think reaching consensus in the PI/PA change will be so easy > > in the ???near future??? (considering that it may require a long > > implementation time), and a middle way proposal looks feasible to > > me. > > but it's not a middle way: it's removing the block on sub-assigning to > other parties, which is the thing that distinguishes PI from PA. Which is one of the things. Other things are "how big will that bag of numbers be" and "what costs are attached to it". Especially the "how big will that bag of numbers be" will certainly be something we'll have to discuss next, shall we decide to open up PI for "more liberate use" (like, will "I want to assing a million /64 to DSL users" be a sufficient reason to get "larger than a /48"?). Consequences to all we do... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
JORDI PALET MARTINEZ wrote: > I don’t think reaching consensus in the PI/PA change will be so easy > in the “near future” (considering that it may require a long > implementation time), and a middle way proposal looks feasible to > me. but it's not a middle way: it's removing the block on sub-assigning to other parties, which is the thing that distinguishes PI from PA. Nick
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
I don’t think reaching consensus in the PI/PA change will be so easy in the “near future” (considering that it may require a long implementation time), and a middle way proposal looks feasible to me. Regards, Jordi -Mensaje original- De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Nick Hilliard <n...@foobar.org> Responder a: <n...@foobar.org> Fecha: miércoles, 8 de noviembre de 2017, 13:10 Para: <jordi.pa...@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) JORDI PALET MARTINEZ wrote: > Fully agree, and I’ve been working around that idea for about a year > already … I’ve something in the kitchen, but still not mature > enought. > > I’m waiting for NCC budget figures to be able to make a proposal that > is sustainable in the long term. I know “money” is not related to > policies, but in this case, even if is only rational behind the > proposal text, I think it is a must. > > Nevertheless, my opinion is that that change may take, as you said, a > longer period of discussion, and I will like to make sure, meanwhile, > cases such as Max one, aren’t “in hold” for deploying IPv6. if you're planning to change this universally some time in the future, it would be simpler and easier to make a step change (i.e. Max's suggestions) in the ipv6 assignment policy now rather than making a fundamental change there first and catching up with other bits of policy later on. Nick ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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.
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
JORDI PALET MARTINEZ wrote: > Fully agree, and I’ve been working around that idea for about a year > already … I’ve something in the kitchen, but still not mature > enought. > > I’m waiting for NCC budget figures to be able to make a proposal that > is sustainable in the long term. I know “money” is not related to > policies, but in this case, even if is only rational behind the > proposal text, I think it is a must. > > Nevertheless, my opinion is that that change may take, as you said, a > longer period of discussion, and I will like to make sure, meanwhile, > cases such as Max one, aren’t “in hold” for deploying IPv6. if you're planning to change this universally some time in the future, it would be simpler and easier to make a step change (i.e. Max's suggestions) in the ipv6 assignment policy now rather than making a fundamental change there first and catching up with other bits of policy later on. Nick
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi Elvis, I think the number of sub-assignments is something that can be very different in different cases and we may end-up with a new case that will not fit the policy. My rational to /64 is that actual IETF work direction is very consistent with a /64 to be used in a single interface (a host having VMs, for example) and I think this match very well what it may be the difference between PI and PA (while we keep it). https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ Regards, Jordi -Mensaje original- De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Elvis Daniel Velea <el...@velea.eu> Responder a: <el...@velea.eu> Fecha: miércoles, 8 de noviembre de 2017, 12:12 Para: <jordi.pa...@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Hi Jordi, Excuse the briefness of this mail, it was sent from a mobile device. > On Nov 8, 2017, at 02:20, JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> wrote: > > b. Arguments Opposing the Proposal > It can be argued that this proposal could increase the number of PI request to RIPE NCC. > > Mitigation/counter-argument: This is not an issue and should not be considered as a “bad-effect”. > > The resulting policy could be used to circumvent the allocation policy, avoiding creating a LIR. > > Mitigation/counter-argument: This seems not to have sense as there must be a justification process anyway, and because the starting point is /48, an ISP willing to connect customers, will really want to be an LIR. Furthermore, if we want to be restrictive on this, we could add a limitation that the maximum sub-assignment can be /64. how about... if we want to be restrictive - instead of limiting the size of the prefix, we limit the number of sub-assignments one can make from a PI? elvis ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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.
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi Nick, Fully agree, and I’ve been working around that idea for about a year already … I’ve something in the kitchen, but still not mature enought. I’m waiting for NCC budget figures to be able to make a proposal that is sustainable in the long term. I know “money” is not related to policies, but in this case, even if is only rational behind the proposal text, I think it is a must. Nevertheless, my opinion is that that change may take, as you said, a longer period of discussion, and I will like to make sure, meanwhile, cases such as Max one, aren’t “in hold” for deploying IPv6. Regards, Jordi -Mensaje original- De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Nick Hilliard <n...@foobar.org> Responder a: <n...@foobar.org> Fecha: miércoles, 8 de noviembre de 2017, 12:24 Para: Gert Doering <g...@space.net> CC: <address-policy-wg@ripe.net>, JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Gert Doering wrote: > both would work to solve the (real) problem at hand, and Jordi's approach > would certainly much easier than trying to come up with unambiguous wording > to "permit some, disallow other" use cases. this is a restatement of the long-standing question about whether the RIPE community should continue with the idea of differentiating between PA and PI address space. If we're going to go down this road, this is a substantial change to make, with far-reaching consequences, and it needs a good deal more attention than a couple of lines in the ipv6 policy doc. Nick ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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.
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Gert Doering wrote: > both would work to solve the (real) problem at hand, and Jordi's approach > would certainly much easier than trying to come up with unambiguous wording > to "permit some, disallow other" use cases. this is a restatement of the long-standing question about whether the RIPE community should continue with the idea of differentiating between PA and PI address space. If we're going to go down this road, this is a substantial change to make, with far-reaching consequences, and it needs a good deal more attention than a couple of lines in the ipv6 policy doc. Nick
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi Jordi, Excuse the briefness of this mail, it was sent from a mobile device. > On Nov 8, 2017, at 02:20, JORDI PALET MARTINEZ> wrote: > > b. Arguments Opposing the Proposal > It can be argued that this proposal could increase the number of PI request > to RIPE NCC. > > Mitigation/counter-argument: This is not an issue and should not be > considered as a “bad-effect”. > > The resulting policy could be used to circumvent the allocation policy, > avoiding creating a LIR. > > Mitigation/counter-argument: This seems not to have sense as there must be a > justification process anyway, and because the starting point is /48, an ISP > willing to connect customers, will really want to be an LIR. Furthermore, if > we want to be restrictive on this, we could add a limitation that the maximum > sub-assignment can be /64. how about... if we want to be restrictive - instead of limiting the size of the prefix, we limit the number of sub-assignments one can make from a PI? elvis
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi, Excuse the briefness of this mail, it was sent from a mobile device. > On Nov 8, 2017, at 02:41, Gert Doeringwrote: > > Hi, > >> On Wed, Nov 08, 2017 at 11:20:34AM +0100, JORDI PALET MARTINEZ wrote: >> Ok, here is it then. Hopefully we have a lot of fun and good noise ;-) >> (that's music?) > > Thanks. > > So, basically, we have two possible approaches here: > > proposed by Max (active proposal): > keep the IPv6 PI policy as somewhat restrictive, trying to find wording > that permits "some generally accepted" use-cases where other people's > devices can get numbers from someone's IPv6 PI block > I agree with Jordi. This is just a patch. This community can do better. > or, > > proposed by Jordi (new direction): > completely remove the restrictions on "letting other people use parts > of someone's IPv6 PI block" > much better, I would support elvis > > both would work to solve the (real) problem at hand, and Jordi's approach > would certainly much easier than trying to come up with unambiguous wording > to "permit some, disallow other" use cases. > > Thanks for your proposal, and now let's see what the community wants :-) > > Gert Doering >-- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AGVorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi, On Wed, Nov 08, 2017 at 11:20:34AM +0100, JORDI PALET MARTINEZ wrote: > Ok, here is it then. Hopefully we have a lot of fun and good noise ;-) > (that's music?) Thanks. So, basically, we have two possible approaches here: proposed by Max (active proposal): keep the IPv6 PI policy as somewhat restrictive, trying to find wording that permits "some generally accepted" use-cases where other people's devices can get numbers from someone's IPv6 PI block or, proposed by Jordi (new direction): completely remove the restrictions on "letting other people use parts of someone's IPv6 PI block" both would work to solve the (real) problem at hand, and Jordi's approach would certainly much easier than trying to come up with unambiguous wording to "permit some, disallow other" use cases. Thanks for your proposal, and now let's see what the community wants :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Ok, here is it then. Hopefully we have a lot of fun and good noise ;-) (that's music?) The main idea is to allow what Max (and many other people) needs in PI, but not having restrictions. For that, what I’m proposing is: 1) Change the actual definition of Assign in 2.6, to: 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, with the exception of Provider Independent (PI). 2) Remove last paragraph in 7. IPv6 Provider Independent (PI) Assignments So, REMOVE: The PI assignment cannot be further assigned to other organisations. Rationale: a. Arguments Supporting the Proposal This proposal will avoid the situations of breaking existing policy when a network using PI is using the addressing space for point-to-point links or in cases such as providing connectivity to employee or visitor devices (BYOD), hot-spots, and similar situations. At this way, regardless of if a single /128 or /64 is sub-assigned, and independently of what technology is used for that (SLAAC, DHCPv6, DHCPv6-PD), the restriction is no longer an issue. b. Arguments Opposing the Proposal It can be argued that this proposal could increase the number of PI request to RIPE NCC. Mitigation/counter-argument: This is not an issue and should not be considered as a “bad-effect”. The resulting policy could be used to circumvent the allocation policy, avoiding creating a LIR. Mitigation/counter-argument: This seems not to have sense as there must be a justification process anyway, and because the starting point is /48, an ISP willing to connect customers, will really want to be an LIR. Furthermore, if we want to be restrictive on this, we could add a limitation that the maximum sub-assignment can be /64. Thoughts? Regards, Jordi -Mensaje original- De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Gert Doering <g...@space.net> Responder a: <g...@space.net> Fecha: miércoles, 8 de noviembre de 2017, 11:09 Para: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Hi, On Wed, Nov 08, 2017 at 10:47:09AM +0100, JORDI PALET MARTINEZ wrote: > So, in the morning of 25th I???ve prepared a draft version and > my co-author hasn???t provided any input back. I just resent it to > him and my next step is to send a copy to the co-chairs and Max in > private in a few seconds, so we can move on from there. Before coming up with finished new proposal text it might be a good idea to present your approach to the list and discuss the general direction, and only then come up with a specific text to take WG feedback into account. This is not the IETF where things have to start with elaborate drafts, we are at liberty to discuss first. Speeds up things a bit :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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.
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi, On Wed, Nov 08, 2017 at 10:47:09AM +0100, JORDI PALET MARTINEZ wrote: > So, in the morning of 25th I???ve prepared a draft version and > my co-author hasn???t provided any input back. I just resent it to > him and my next step is to send a copy to the co-chairs and Max in > private in a few seconds, so we can move on from there. Before coming up with finished new proposal text it might be a good idea to present your approach to the list and discuss the general direction, and only then come up with a specific text to take WG feedback into account. This is not the IETF where things have to start with elaborate drafts, we are at liberty to discuss first. Speeds up things a bit :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Responding to Sander and Gert, in a single email … Actually, I fully agree with you, and this is what I’ve said to my co-author in Dubai, during the meeting, that it will be better to just draft this together with Max, but we wanted to clarify first among ourselves. So, in the morning of 25th I’ve prepared a draft version and my co-author hasn’t provided any input back. I just resent it to him and my next step is to send a copy to the co-chairs and Max in private in a few seconds, so we can move on from there. Regards, Jordi -Mensaje original- De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Gert Doering <g...@space.net> Responder a: <g...@space.net> Fecha: miércoles, 8 de noviembre de 2017, 10:41 Para: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Hi, On Wed, Nov 08, 2017 at 10:33:36AM +0100, JORDI PALET MARTINEZ wrote: > I think Jan comments (in the meeting, hopefully he can repeat here) are very relevant, and I???ve a draft policy proposal in that direction, I???m waiting for my co-author review to submit it. Multiple parallel proposals touching the same area of the same policy document are never a good idea. So if you want to work on the IPv6 PI policy, please join forces with Max (or wait for his proposal to finish, either way). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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.
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi, On Wed, Nov 08, 2017 at 10:33:36AM +0100, JORDI PALET MARTINEZ wrote: > I think Jan comments (in the meeting, hopefully he can repeat here) are very > relevant, and I???ve a draft policy proposal in that direction, I???m waiting > for my co-author review to submit it. Multiple parallel proposals touching the same area of the same policy document are never a good idea. So if you want to work on the IPv6 PI policy, please join forces with Max (or wait for his proposal to finish, either way). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi Jordi, > I think Jan comments (in the meeting, hopefully he can repeat here) are very > relevant, and I’ve a draft policy proposal in that direction, I’m waiting for > my co-author review to submit it. If you are talking about a RIPE policy proposal: please don't. Having multiple "competing" policy proposals on the same subject active at the same time tends to make it impossible to get consensus on anything. If you want to contribute please work with the current policy proposer. The end goal should be working group consensus, so getting consensus with the current proposer on the next version should only be a small effort in that direction :) Cheers, Sander
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
What I’m not supporting is the *current* text (this version, as I understand we are discussing this version). I feel that the current version is solving partially Max case, but even in his case, if he decides to provide /64 for each hot-spot customer, this proposal will not work. I think Jan comments (in the meeting, hopefully he can repeat here) are very relevant, and I’ve a draft policy proposal in that direction, I’m waiting for my co-author review to submit it. Regards, Jordi -Mensaje original- De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Gert Doering <g...@space.net> Responder a: <g...@space.net> Fecha: miércoles, 8 de noviembre de 2017, 10:26 Para: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Hi, On Wed, Nov 08, 2017 at 10:12:59AM +0100, JORDI PALET MARTINEZ wrote: > Sorry, I thought that you also consider the opinions in the meeting, so just repeating myself, I???m against this proposal. I find my "before we enter discussion" slide on this quite unambiguous. The discussion at the meeting is relevant to get a feel for the room, and help the proposer to get guidance in which direction the proposal should be developed. For the sake of openness and transparency, the *list* is what is relevant. But besides that, your statement is not helping. You have voiced support at the May meeting for the general proposal, and now oppose "the proposal", without further qualifying. So what, do you support loosening up the IPv6 PI policy, and just do not agree with the v2.0 wording, or do you generally oppose any move into that direction? > I know, a policy can probably never be perfect at once, but I > will prefer, in this case, having a better solution than an > intermediate step to a better one, as otherwise we are complicating > the interpretation of many other aspects in the overall IPv6 policy. There are no perfect policies. There are workable compromises that iteratively get adjusted to changed community requirements. The IPv6 PI policy is a good example: it's a compromise, because we did not know 10+ years ago what a "perfect!" policy would have looked like (and 10+ years ago, what people assumed would be needed is different from the landscape today) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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.
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Gert Doering wrote: > So: > >>> We encourage you to read the proposal, impact analysis and draft >>> document and send any comments to>>> before 17 November 2017. > > Please speak up *here* if you have opinions on this proposal. Looks sensible. I support the proposal. Nick
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi, On Wed, Nov 08, 2017 at 10:12:59AM +0100, JORDI PALET MARTINEZ wrote: > Sorry, I thought that you also consider the opinions in the meeting, so just > repeating myself, I???m against this proposal. I find my "before we enter discussion" slide on this quite unambiguous. The discussion at the meeting is relevant to get a feel for the room, and help the proposer to get guidance in which direction the proposal should be developed. For the sake of openness and transparency, the *list* is what is relevant. But besides that, your statement is not helping. You have voiced support at the May meeting for the general proposal, and now oppose "the proposal", without further qualifying. So what, do you support loosening up the IPv6 PI policy, and just do not agree with the v2.0 wording, or do you generally oppose any move into that direction? > I know, a policy can probably never be perfect at once, but I > will prefer, in this case, having a better solution than an > intermediate step to a better one, as otherwise we are complicating > the interpretation of many other aspects in the overall IPv6 policy. There are no perfect policies. There are workable compromises that iteratively get adjusted to changed community requirements. The IPv6 PI policy is a good example: it's a compromise, because we did not know 10+ years ago what a "perfect!" policy would have looked like (and 10+ years ago, what people assumed would be needed is different from the landscape today) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Hi Gert, all, Sorry, I thought that you also consider the opinions in the meeting, so just repeating myself, I’m against this proposal. I know, a policy can probably never be perfect at once, but I will prefer, in this case, having a better solution than an intermediate step to a better one, as otherwise we are complicating the interpretation of many other aspects in the overall IPv6 policy. Regards, Jordi -Mensaje original- De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Gert Doering <g...@space.net> Responder a: <g...@space.net> Fecha: miércoles, 8 de noviembre de 2017, 9:46 Para: Marco Schmidt <mschm...@ripe.net> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Dear Working Group, On Thu, Oct 19, 2017 at 03:08:07PM +0200, Marco Schmidt wrote: > Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the Review Phase. I'm a bit disappointed by the reactions of the WG on this - one voice of support on the list, silence otherwise. Then, quite vocal opposition at the RIPE meeting in dubai (to the current version, v2.0, while still in favour of the general idea to loosen up the IPv6 PI policy somewhat). Afterwards, silence again. But if it's not on the list, it did not happen, as per the ever-repeated explanation at the meetings. So, does this mean "the WG supports the current form of this proposal", and "the outburst at the RIPE meeting was not meant as sustained opposition"? So: > We encourage you to read the proposal, impact analysis and draft document and send any comments to <address-policy-wg@ripe.net> before 17 November 2017. Please speak up *here* if you have opinions on this proposal. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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.
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Dear Working Group, On Thu, Oct 19, 2017 at 03:08:07PM +0200, Marco Schmidt wrote: > Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the > Review Phase. I'm a bit disappointed by the reactions of the WG on this - one voice of support on the list, silence otherwise. Then, quite vocal opposition at the RIPE meeting in dubai (to the current version, v2.0, while still in favour of the general idea to loosen up the IPv6 PI policy somewhat). Afterwards, silence again. But if it's not on the list, it did not happen, as per the ever-repeated explanation at the meetings. So, does this mean "the WG supports the current form of this proposal", and "the outburst at the RIPE meeting was not meant as sustained opposition"? So: > We encourage you to read the proposal, impact analysis and draft document and > send any comments tobefore 17 November 2017. Please speak up *here* if you have opinions on this proposal. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Dear Max, On 2017-10-19 15:33:18 CET, Maximilian Wilhelm wrote: > There seem's to be some glitch in the comparison between the proposal > versions. The diff seems to be in the wrong direction. Could you have > a look at that? > Thank you for raising this issue. Yesterday we deployed an update to our diff tool, which now shows the content of the later proposal version as the added content. You can see an example of this in your proposal 2016-04, "IPv6 Sub-assignment Clarification": https://www.ripe.net/s/y73A Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
+1 for this proposal. The only thing that I'm little bit scared of is the last paragraph of the section A of the impact analysis. Some operators could use this proposal as an apology for not deploying the network properly, like when they use (pseudo-)bridges instead of routers, just to avoid "sub-delegation". But I don't think this is a big problem, especially now when most entities are becoming LIRs just to get some more v4 addresses. I believe this proposal goes in the right direction and conforms with common sense on what should be assignments used for. -- Ondřej Caletka smime.p7s Description: Elektronicky podpis S/MIME
Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Anno domini 2017 Marco Schmidt scripsit: Hi Marco, > Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the > Review Phase. Cool, thanks for that! > The goal of this proposal is to re-define the term "sub-assignment" for IPv6. > > This proposal has been updated following the last round of discussion and is > now at version v2.0. > Some of the differences from version v1.0 include: > - the scope is extended to all IPv6 assignments > - it defines that the provision of separate IPv6 addresses is not considered > a sub-assignment > > The RIPE NCC has prepared an impact analysis on this latest proposal version > to support the community’s discussion. You can find the full proposal and > impact analysis at: > https://www.ripe.net/participate/policies/proposals/2016-04 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2016-04/draft There seem's to be some glitch in the comparison between the proposal versions. The diff seems to be in the wrong direction. Could you have a look at that? Thanks! Best Max -- "I have to admit I've always suspected that MTBWTF would be a more useful metric of real-world performance." -- Valdis Kletnieks on NANOG
[address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)
Dear colleagues, Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the Review Phase. The goal of this proposal is to re-define the term "sub-assignment" for IPv6. This proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - the scope is extended to all IPv6 assignments - it defines that the provision of separate IPv6 addresses is not considered a sub-assignment The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2016-04 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2016-04/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments tobefore 17 November 2017. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum