October 2017 - address-policy-wg

2016-04 Review Phase (IPv6 Sub-assignment Clarification)
by Marco Schmidt 22 Jan '18

22 Jan '18

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 to <address-policy-wg(a)ripe.net> before 17 November 2017. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

24 103

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

Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
by Aleksey Bulgakov 07 Oct '17

07 Oct '17

Hi, all! I agree with Yury and oppose this proposal. It would be better to return unused allocations more than 24 months not from the last /8 pool. Many companies have /16, maybe more for free. 6 Окт 2017 г. 20:22 пользователь "NTX NOC" <noc(a)ntx.ru> написал: Greetings! I Oppose this proposal. Minimum routing block is /24 and new LIR will be too difficult to build network in different locations. Most new LIR are small companies. For other half of the companies - they will have to route a lot of small block as 24, routing table will grow high. Nothing useful in this case. I wish this allocation should be greater, les say /21 as in apnic. If everybody force IPv6 - then better to distribute IPv4 and go to v6 With current rate of Ipv4 distribution ipv4 will be enough for many years. And we should take in mind that time to time RIPE get Ips back to reserve pool from the closed companies and etc. For people who always care about IPv4 reserved the answer is next - there big Ipv4 reserved space "for future use" according RFC, my opinion that people should look in that direction. I support it too. NTX NOC Yury Bogdanov On 21.09.2017 14:43, Marco Schmidt wrote: > 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 >

2 1