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

2006-06 Discussion Period extended until 29 November 2006 (IPv4 Maximum Allocation Period)
by Filiz Yilmaz 18 Oct '06

18 Oct '06

PDP Number: 2006-06 IPv4 Maximum Allocation Period Dear Colleagues The Discussion Period for the proposal 2006-06 has been extended until 29 November 2006. This proposal is to have the RIPE NCC allocate address space to Local Internet Registries (LIRs) based on their one-year needs. In other words, it suggests setting a maximum allocation period of 12 months. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-06.html We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

New IPv6 block allocated to RIPE NCC
by leo vegoda 18 Oct '06

18 Oct '06

[Apologies for duplicate mails] Dear Colleagues, The RIPE NCC received the IPv6 address range 2a00::/12 from the IANA in October 2006. This allocation expands two previous allocations. We will begin allocating from this new space in the near future. The minimum allocation size for this /12 has been set at /32. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

Re: [ppml] Fwd: Keeping in reserve
by Iljitsch van Beijnum 05 Oct '06

05 Oct '06

[Originally to ppml, CC to address-policy@ripe, prune as necessary] On 5-okt-2006, at 18:17, David Conrad wrote: > Is there any reason PI /48s shouldn't be allocated with the > bisection method, thus removing the need to reserve space? The goal of filtering in BGP is either to keep out accidentally injected prefixes, or keep out both accidentially and maliciously injected prefixes. This means that a reasonable filter, i.e., one that can be configured on a router with a relatively limited number of filter rules, must allow through all prefixes that match legitimate allocations, and reject as much of everything else as possible. This means that ideally, from a certain block of address space, prefixes of one size are allocated sequentially with no unused space between them. For instance: 192.0.0.0/24 -> /28s: 192.0.0.0/28 192.0.0.16/28 ... 192.0.0.192/28 192.0.0.208/28 In this example, only blocks above 192.0.0.208/28 can be successfully used to get around the filter, either for the purpose of hijacking unused address space for purposes like spamming, or to overload routers by injecting large numbers of bogus prefixes. If we now reserve a /26 for every user of a /28, we'd have: 192.0.0.0/28 192.0.0.64/28 ... 192.0.2.0/28 192.0.2.64/28 So a filter would have to allow 192.0.0.0/22 -> /26 - /28. This gives an attacker the opportunity to inject three malicious /28 prefixes between any two legitimate /28s. Worse, when someone grows out of a / 28 and gets a /27, such as 192.0.0.64/27, an attacker can inject 192.0.0.64/28 + 192.0.0.80/28, which cover the same address space but the longest match first rule makes packets flow toward the attacker rather than the real holder of the addresses. For this reason and because of temporary instability when moving from a smaller to a larger prefix, or maybe because of simple laziness or cluelessness, the real holder of the address space may choose to inject both 192.0.0.64/28 and 192.0.0.80/28 and maybe also 192.0.0.64/27. This negates the purpose of keeping some extra space in reserve between allocations. In IPv4 we have to be careful not to give too much space away, but in IPv6 there is absolutely no reason to skimp when people come back for seconds. So if a /48 isn't enough, don't grow to a /47 or even a /44, just give a /40 and then a /32. The number of extra prefixes in the routing table that this results in is minimal because even a /48 is more than enough for the majority of organizations, and it allows for much stricter filters. And it avoids fragmenting the address space. With the bisection method, you'd have to use even more liberal filters and allow between /25 and /28 in this example. All in all, it would be best if for every block of address space, only a fixed size allocations are given out.

2 1

NRO Number Counci Elections: Successful Candidate Announced
by Paul Rendek 05 Oct '06

05 Oct '06

[Apologies for duplicate e-mails] Dear Colleagues, Dave Wilson, HEAnet, has been nominated from the RIPE NCC service region to take the vacant seat on the Number Resource Organization (NRO) Number Council (NC). Voting took place during the Plenary session of the RIPE 53 Meeting in Amsterdam at 09:00 - 10:30, Thursday 5 October, 2006. As the representative appointed by the Internet community for the NRO NC seat, Dave Wilson will serve a three-year term beginning on 1 January 2007. The term of Sabine Jaume, who was elected in January 2004, expires in December 2006. For more information about the NRO NC, nominations and the election process, see: http://www.ripe.net/info/resource-admin/nro2006/ Regards, Paul Rendek Head of Member Services & Communications RIPE NCC

1 0

2006-07 New Policy Proposal (Minimum IPv4 Assignment Window)
by Filiz Yilmaz 04 Oct '06

04 Oct '06

PDP Number: 2006-07 Minimum IPv4 Assignment Window Dear Colleagues, A new RIPE Policy has been made and is now available for discussion. This proposal suggests the minimum Assignment Window (AW) available to LIRs should be raised from zero (0) to /21 (2048 IPv4 addresses). Because the sub-allocation policy references the AW policy, the sub-allocation policy also needs to be updated. This proposal suggests that the maximum sub-allocation should be kept at /20 (4096 IPv4 addresses). You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-07.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 10 October 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

5 7

2006-06 New Policy Proposal (IPv4 Maximum Allocation Period)
by Filiz Yilmaz 04 Oct '06

04 Oct '06

PDP Number: 2006-06 IPv4 Maximum Allocation Period Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. This proposal is to have the RIPE NCC allocate address space to Local Internet Registries (LIRs) based on their one-year needs. In other words, it suggests setting a maximum allocation period of 12 months. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-06.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 10 October 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

3 2

Data Protection Task Force - Ref: RIPE53 DB-WG Draft Agenda V3. item C
by Wilfried Woeber, UniVie/ACOnet 04 Oct '06

04 Oct '06

Dear Community, the logistical infrastructure for the Data Protection Task Force has been set up by the NCC. It is available at http://www.ripe.net/ripe/tf/index.html We are trying to get together a reasonably diverse mix of people for this task force, representing the various roles, activities and types of interest. The TF will be presented and discussed on Fr. morning in the DB-WG session where we will try to collect the initial population. If you can't make it to the DB-WG meeting, please indicate your interest by personal mail to Jochem de Ruig and myself. Please read up on the TF's mandate, the goals and logistics, and consider stepping forward to *actively* contribute! Thank you. See you Friday morning, Wilfried.

2 1

Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01)
by JORDI PALET MARTINEZ 28 Sep '06

28 Sep '06

Hi all, Sorry confused stats. Ignore the previous email ... As the discussion period for this proposal (http://www.ripe.net/ripe/policies/proposals/2006-01.html) is almost over, I will like to ask for the latest inputs in order to further decide how to proceed. Filiz arranged some stats about the discussion (thanks a lot for that !) last July, and afterwards, even if the discussion period has been extended, I don't recall having seen new comments. The stats don't include my own postings: >>> - there were 9 posts from 8 individuals about it. >>> >>> - 5 people supported it. 1 of these made some comments though, that he >>> prefers a longer prefix than a /32 clearly in his mail. >>> >>> - 1 person stated he supports "PI" but he is not supporting this proposal. >>> >>> - 2 people said "No". So someone else will like to say anything new or clarify their view in favor or opposition to the proposal ? Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

10 18

PI vs PA in routing table
by Max Tulyev 28 Sep '06

28 Sep '06

Hello! Is there a graphs shows how much prefixes in global route table are PA and how much - PI (maybe in percents)? And also this one year-by-year (monthly?)? Maybe there is no real "route table PI pollution" trouble in the real world? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

4 4

2006-04 Draft Document will be produced (Contact e-mail Address Requirements)
by Filiz Yilmaz 28 Sep '06

28 Sep '06

PDP Number: 2006-04 Contact e-mail Address Requirements Dear Colleagues, The discussion period for the proposal 2006-04, Contact e-mail Address Requirements has ended. This proposal suggests that working and up-to-date contact e-mail addresses should be maintained at all times for address space that is registered in the RIPE Database. A draft document will now be prepared for review. We will publish the document in about four weeks. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-04.html Regards, Filiz Yilmaz RIPE NCC Policy Development Officer

9 16