- address-policy-wg - mailman.ripe.net

inconsistency in 2016-04
by JORDI PALET MARTINEZ 19 Jan '18

19 Jan '18

(sorry Jim ! subject replaced) Hi Sander, Below in-line. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces(a)ripe.net> en nombre de Sander Steffann <sander(a)steffann.nl> Fecha: viernes, 19 de enero de 2018, 12:13 Para: JORDI PALET MARTINEZ <jordi.palet(a)consulintel.es> CC: <address-policy-wg(a)ripe.net> Asunto: Re: [address-policy-wg] what does consensus mean Hi, > 1) Temporary always ? clearly not for point-to-point links, no-sense for data centers? Indeed, this is what I asked Marco. > 2) Single address (/128) for a single device (so the device can't use privacy? Utopia!), or do we allow if the devices get a single-prefix, it uses multiple addresses out of that prefix (so we allow VMs in the device also) The policy talks about single-address increments. It doesn't say "one address", it says "separate addresses" (plural), which allows for privacy extensions etc. Right, but 6) IA say: "... There are cases where a /64 is needed per customer to provide a separate address ..." and 8) IA say: "... by using single IPv6 addresses for End User devices and services ..." furthermore it say "... provided no prefixes will be provided to other entities ..." I think this can be sorted out replacing in the IA "provided no more than a single prefix will be provided to other entities." > 3) Can the device use any technology (such as prefix sharing, eg. RFC7278), to also use addresses from a single prefix for other devices (same user) Technology used is out of scope here. I used the technology as an example, what I'm referring is if the single prefix can be shared by other devices of the user of a hot-spot (example, the hotel gives me a single /64 in the WiFi, but I've several devices). The point here is, clarification 2 above will solve the problem for multiple addresses in a single prefix, 3) may solve the problem for multiple devices with the same prefix. For both of them we may need to clarify if Max "not prefixes" is meaning also a single prefix or "not multiple prefixes", which is I think the major contradiction with the IA or NCC interpretation according to mail exchange with Marco. Cheers, Sander ********************************************** 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.

4 6

policy text or anything else?
by JORDI PALET MARTINEZ 19 Jan '18

19 Jan '18

Hi all, I've changed the subject, because I want to talk here in general about our policy process, not any specific policy. I've tried to find where in our process, states that in addition to the policy text itself, other inputs during the PDP matter. If there is such confirmation, could the NCC tell me how to find it? I understand that this may have been our "practice", but maybe we did wrong. Let me explain why I think is wrong, and consequently we need to correct it. Let's suppose I'm an organization asking for the first time IPv6 space, I will find the actual policy at https://www.ripe.net/publications/docs/ripe-684 I read across it, and I obviously will decide, based on my needs what choices I've to apply for. I've not followed the PDP since the first time we discussed an IPv6 policy, so I'm missing all the policy proposals text, arguments, rationales, impact analysis, etc. Because that, I'm applying with a different view from someone that has been for ages in the addressing policy list and following it, and possible not taking advantages of perspectives that are "in between lines" in the policy text, which may make a huge difference on my request vs a "follower" of the PDP. I would agree with that (using not only the policy text, but also all the PDP documents) IF when I go to the ripe-684 document, I've direct links in every section of the policy text, pointing to the PDP documents that have been used to modify that section. I hope everybody understand what I mean, not sure if is so easy to explain. Now, is that realistic? It will make our policy text so difficult to read ... and a very very very long (and always increasing) document. So, my conclusion: what it matters is only policy text, other documents are relevant to explain it, but not to add "modifications" to the reading of that text so not conflicts should be there (unless undiscovered). I agree that we are humans and we can make mistakes, and we may need to go to new rounds of PDP to correct that, new proposals, or whatever, but even if it takes some extra work, policy text must be refined if discrepancies are perceived. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces(a)ripe.net> en nombre de Marco Schmidt <mschmidt(a)ripe.net> Fecha: martes, 16 de enero de 2018, 16:05 Para: <address-policy-wg(a)ripe.net> Asunto: 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 ********************************************** 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.

1 0

Re: [address-policy-wg] inconsistency in 2016-04 (was: what does consensus mean)
by Sander Steffann 19 Jan '18

19 Jan '18

Hi Jim, > PLEASE put those comments in a different thread which makes it clear you're discussing detail about 2016-4 (or whatever). Thanks. > > This thread's supposed to be about an entirely different topic. Indeed, my apologies. There were so many things going on that I lost track as well :) Cheers, Sander

1 0

permanently % denied
by Patrick Schauer 10 Jan '18

10 Jan '18

Why your service blocked many of my customers? how can we delete your entries? Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

DMARC Solution Applied to this Mailing List
by Adam Castle 18 Dec '17

18 Dec '17

Dear Working Group, As more email providers enable Domain Message Authentication Reporting & Conformance (DMARC), some people find they can no longer receive emails from the mailing lists they are subscribed to. We have deployed a Mailman setting change to address this problem. After consultation with the RIPE Working Group Chairs, we have enabled the DMARC "Munge From" setting on all RIPE mailing lists. This means that if your email service provider has DMARC enabled, you will continue to receive all emails sent to this mailing list, but the "From" part of the header will change. If you don't have DMARC enabled, you won't see any change to the emails you receive from this mailing list. You can find more information about how we have been handling DMARC in the following RIPE Labs articles: https://labs.ripe.net/Members/adam_castle/dmarc-and-the-ripe-ncc https://labs.ripe.net/Members/adam_castle/ripe-mailing-lists-and-dmarc To ensure all working group participants are aware of the changes, I am sending this mail to all working groups. If you have any questions or encounter any issues on this mailing list, please let me know. Many thanks. Adam Castle Web Services Manager RIPE NCC

1 0

2016-04 Review Phase Extended (IPv6 Sub-assignment Clarification)
by Marco Schmidt 27 Nov '17

27 Nov '17

Dear colleagues, Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the extended Review Phase. The goal of this proposal is to re-define the term "sub-assignment" for IPv6. You can find the full proposal and the RIPE NCC 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 extended 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. We encourage you to read the proposal, impact analysis and draft document and send any comments to <address-policy-wg(a)ripe.net> before 27 December 2017. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

3 2

IXP peering lan reachability
by Nick Hilliard 24 Oct '17

24 Oct '17

Following up on Andrea's presentation earlier (for the record, ripe75, apwg session #1, tuesday morning), there aren't compelling reasons for the RIPE NCC to get involved in whether an IXP announces their peering LAN prefix into the DFZ. It's really a matter of local policy for the ixp as to whether they want this to happen, and if a prefix is announced into the dfz, this doesn't make any statement one way or another about what the prefix is used for. Lots of IXPs announce their peering lan netblocks and many others choose not to. The reasons for announcing relate mostly to debugging and problem diagnosis, e.g. ping / traceroute. We know of several IXP members at various INEX LANs who use external reachability checking services to monitor their service's uptime, which is a good thing to do and they see a benefit from this, and they particularly don't want to see this benefit going away. Regarding traceroute, the udp/icmp replies can be dropped if the network you're tracing from has uRPF enabled, which makes problem diagnosis troublesome. The reason most IXPs don't announce their peering LANs relates to protecting against DDoS attacks. Although we've had occasional DDoS attacks launched against our infrastructures in the past, we have not had service-affecting problems as a result. If a service affecting problem happens, we can announce the blocks with no-export or no-announce, which would reduce the blast radius - or we could completely drop the announcement, if that didn't work. We're aware that the experience at other IXPs - especially larger IXPs - can be different, but given that announcing the blocks provides useful telemetry and diagnosis capabilities, and we've not had problems in the last, we don't see any particular reason to stop announcing the range. The risk/return ratio doesn't justify it. The experiences of other IXPs may be different regarding ddos problems, but many (most?) organisations connected to IXPs use "redistribute connected" to inject the peering LAN prefix into their IGPs, and the largest IXPs have visibility to most of the Internet prefixes, so in practice, not announcing the blocks makes less difference to DDoS than it might appear. I'd politely suggest that this is an area that the RIPE NCC should not get involved in, especially from the point of view of implicitly issuing recommended practice by implying that there is a problem with doing this. The IXP associations are better placed to gather consensus for creating best practices, and there is no general consensus in the IXP community on this issue. As regards using this as a metric for determining whether an ixp address assignment is being used for legitimate purposes, I'd suggest that this is of only marginal use at best. By all means run a port scan to see if there is any obvious mis-use (e.g. services listening on www/smtp/etc), but the presence or absence of the route in the dfz doesn't mean anything one way or another. Nick CTO, INEX

6 7

2017-03 Policy Proposal Withdrawn (Reducing Initial IPv4 Allocation, Aiming to Preserve a Minimum of IPv4 Space for Newcomers)
by Marco Schmidt 23 Oct '17

23 Oct '17

Dear colleagues, The policy proposal 2017-03, "Reducing Initial IPv4 Allocation, Aiming to Preserve a Minimum of IPv4 Space for Newcomers" has been withdrawn. The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive… Reason for withdrawal: The proposers felt unable to create a second draft that addressed conflicting objections. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Confusion
by Aleksey Bulgakov 20 Oct '17

20 Oct '17

Hi, all. As you can read here https://www.ripe.net/ripe/mail/archives/ncc- announce/2016-July/001066.html Transfer of resources between LIR accounts of the same member will fall under the transfer policy. This aligns the transfer of resources between LIR accounts of the same member with the transfer procedures the RIPE NCC applies to transfers between LIR accounts of different members. The transfer policy will now apply to all transfers, regardless of whether the transfer is between the same or different members. In practice, this means that the IPv4 allocation will only be transferable between LIR accounts of the same member after 24 months. But if you go to transfer policy, you can see the next This restriction does not prevent the resources from being transferred due to further mergers or acquisitions within the 24-month period. So, I see confusion between policies and executive board desision .

3 2

2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
by Marco Schmidt 08 Oct '17

08 Oct '17

Dear colleagues, A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space", is now available for discussion. The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation directly from the RIPE NCC before. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-03/ As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the RIPE Working Group Chairs, decides how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 20 October 2017. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

41 93