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

>>: Re: [address-policy-wg] 2006-07 Discussion Period extended until 29 November 2006 (Minimum IPv4 Assignment Window)
by Dmitriy V Menzulskiy 19 Oct '06

19 Oct '06

I support those changes. Arguments are the same as Cathy gives. WBR, Dmitry Menzulskiy DM3740-RIPE ----- Переслано: Dmitriy V Menzulskiy/BeeLine дата: 19.10.2006 18:30 ----- address-policy-wg-admin(a)ripe.net написано 19.10.2006 15:26:57: > > I support changing the assignment window to a /21 or even something > larger. When I worked for a company that was a RIPE LIR I found > that the small AW made it very difficult to do my job. I feel it's > more appropriate to give LIRs information about how to make wise and > documented assignments to customers and then assume they're adults > and that they will do the right thing. If they fail in this then > make it harder for them to get a subsequent allocation. Making them > ask permission for every customer assignment is just a pain. > > Thanks! > ---Cathy > > On 10/18/06, Filiz Yilmaz < filiz(a)ripe.net> wrote: > PDP Number: 2006-07 > Minimum IPv4 Assignment Window > > Dear Colleagues > > The Discussion Period for the the proposal 2006-07 has been extended > until 29 November 2006. > > > 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 policy proposal and send your comments > to <address-policy-wg(a)ripe.net>. > > Regards > > Filiz Yilmaz > RIPE NCC > Policy Development Officer >

1 0

Re: [address-policy-wg] 2006-07 Discussion Period extended until 29 November 2006 (Minimum IPv4 Assignment Window)
by cja＠daydream.com 19 Oct '06

19 Oct '06

I support changing the assignment window to a /21 or even something larger. When I worked for a company that was a RIPE LIR I found that the small AW made it very difficult to do my job. I feel it's more appropriate to give LIRs information about how to make wise and documented assignments to customers and then assume they're adults and that they will do the right thing. If they fail in this then make it harder for them to get a subsequent allocation. Making them ask permission for every customer assignment is just a pain. Thanks! ---Cathy On 10/18/06, Filiz Yilmaz <filiz(a)ripe.net> wrote: > > PDP Number: 2006-07 > Minimum IPv4 Assignment Window > > Dear Colleagues > > The Discussion Period for the the proposal 2006-07 has been extended > until 29 November 2006. > > > 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 policy proposal and send your comments > to <address-policy-wg(a)ripe.net>. > > Regards > > Filiz Yilmaz > RIPE NCC > Policy Development Officer > > >

1 0

2006-07 Discussion Period extended until 29 November 2006 (Minimum IPv4 Assignment Window)
by Filiz Yilmaz 18 Oct '06

18 Oct '06

PDP Number: 2006-07 Minimum IPv4 Assignment Window Dear Colleagues The Discussion Period for the the proposal 2006-07 has been extended until 29 November 2006. 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 policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

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