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

Re: [address-policy-wg] [policy-announce] 2011-04 Discussion Period extended until 30 January (Extension of the Minimum Size for IPv6 Initial Allocation)
by Jan Zorz ＠ go6.si 02 Jan '12

02 Jan '12

On 1/2/12 3:10 PM, Emilio Madaio wrote: > Dear Colleagues, > > The text of RIPE Policy Proposal 2011-04, "Extension of the Minimum > Size for IPv6 Initial Allocation", has been revised based on the > community feedback received on the mailing list. We have published > the new version (version 2.0) today. As a result, a new Discussion > Phase is set for the proposal. > > Highlights of the changes in version 2.0 are: > > - The proposed new section 5.1.2 was reworded > - Section 5.7 was not removed but it was reworded Hi, Emilio, thnx for your efforts and all the help with this proposal. Just to add my .2 cents - we considered Remco's and James's suggestions, first one to give out /32 by default and give out more only if LIR asks for it (Remco) and we re-added section 5.7 with clarification, that every holder of legacy /32 can ask for extension of allocation. This is what we heard from you - community - in last few months of discussion. Hope that we made this proposal more acceptable for everyone. Thnx for all your input, Jan Zorz

1 0

2011-04 Discussion Period extended until 30 January (Extension of the Minimum Size for IPv6 Initial Allocation)
by Emilio Madaio 02 Jan '12

02 Jan '12

Dear Colleagues, The text of RIPE Policy Proposal 2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation", has been revised based on the community feedback received on the mailing list. We have published the new version (version 2.0) today. As a result, a new Discussion Phase is set for the proposal. Highlights of the changes in version 2.0 are: - The proposed new section 5.1.2 was reworded - Section 5.7 was not removed but it was reworded You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-04 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net> before 30 January 2012. Regards, Emilio Madaio Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] status of 2011-02
by poty＠iiat.ru 13 Dec '11

13 Dec '11

>... we are constraining the IPv6 > address distribution because of ...? > > Jan > There are so many people using as the main and the last argument the concern about weak distribution of IPv6, that I'm personally becoming against anything they suggest. Vladislav Potapov Ru.iiat

6 5

Update in the RIPE document for IPv6 Allocation and Assignment policies
by Emilio Madaio 07 Dec '11

07 Dec '11

Dear colleagues, An editorial correction has been made to ripe-523 "IPv6 Address Allocation and Assignment Policy". The updated document has been renumbered to ripe-538. It is available at: http://www.ripe.net/ripe/docs/ripe-538 There was a mismatch between the policy text and the index title for section 5.4.2. This mismatch occurred between the updates from ripe-421 to ripe-450. Apologies for any inconvenience caused. Kind regards, Emilio Madaio Policy Development Officer RIPE NCC

1 0

RIPE NCC address request retracted
by Axel Pawlik 07 Dec '11

07 Dec '11

Dear colleagues, as a matter of good housekeeping I would like to announce that the RIPE NCC has retracted its request for addresses for "Business Operations", as presented at RIPE 63 (http://ripe63.ripe.net/presentations/53-resource-request.pdf). kind regards, Axel Pawlik

7 8

128.0.0.0/16 configured as martians in some routers
by Alex Le Heux 05 Dec '11

05 Dec '11

Dear Colleagues, The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space. All allocations that were already issued have been exchanged and for now we will hold this space in quarantine. We urge everyone to change the default behaviour of their Juniper routers: set routing-options martians 128.0.0.0/16 orlonger allow set routing-options martians 191.255.0.0/16 orlonger allow set routing-options martians 223.255.255.0/24 exact allow 128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project: http://www.ris.ripe.net/debogon/ To facilitate testing, the following prefixes are being announced: prefix pinagble address 128.0.0.0/16 128.0.0.1 128.0.8.0/21 128.0.8.1 128.0.24.0/24 128.0.24.1 Best regards, Alex Le Heux Policy Implementation Co-ordinator RIPE NCC

3 3

Final minutes from RIPE 62
by Emilio Madaio 01 Dec '11

01 Dec '11

Dear colleagues, The minutes from the Address Policy Working Group session from RIPE 62 were approved during RIPE 63. The minutes are available here: http://www.ripe.net/ripe/groups/wg/ap/minutes/minutes-from-ripe-62 Best Regards, Emilio Madaio Policy Development Officer RIPE NCC

2 1

Policy Proposal 2010-01 "Temporary Internet Number Assignment Policies" implemented
by Radha Ramphul 30 Nov '11

30 Nov '11

[Apologies for duplicate emails] Dear Colleagues, We are pleased to announce that RIPE Policy Proposal 2010-01,"Temporary Internet Number Assignment Policies", has been implemented. The RIPE NCC is now ready to accept requests for Temporary Internet Number Assignments under this policy. The full proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2010-01 The new policy "Temporary Internet Number Assignment Policies" is available at: https://www.ripe.net/ripe/docs/ripe-526 The following documents now appear online as part of this policy implementation. 1. A new contract template has been formulated which can be used as the agreement between LIRs and End-users. It can be downloaded at: http://ripe.net/lir-services/resource-management/temp-assign-agreement 2. A new request template (currently in text format only) is now available. The LIR portal version will be coming soon. http://www.ripe.net/ripe/docs/ripe-536 3. Supporting notes explaining the various sections of the form and how to complete them have been added as well. http://www.ripe.net/ripe/docs/ripe-535 4. A new FAQ page can be accessed at: https://www.ripe.net/lir-services/resource-management/number-resources/temp… The following resources have been reserved for this purpose: IPv4: 151.216.0.0/13 16-bit ASN: AS58352-AS58367 No reservations have been made for IPv6 and 32-bit ASN. Regards Radha Ramphul RIPE NCC Registration Services

1 0

2011-04, "Extension of the Minimum Size for IPv6 Initial Allocation"
by James Blessing 21 Nov '11

21 Nov '11

Hi all, It seems that the consensus is that up to a /29 is the right amount of space for the majority of networks, if that is the case I've think we should add the following: == 5.1.x Organisations that have already received their initial allocations are able to request additional address space up to a /29 without supplying of further documentation as if they were a first time requestor. == The logic being that this solves the problem for networks who deployed before this change and avoids the issues with HD ratio (which I think needs some looking at, but not here) J -- James Blessing 07989 039 476

25 39

proposal 2011-04, proposal 2011-05, concept document: IPv6 PA/PI unification, intransparent ip-eaters
by chrish＠consol.net 15 Nov '11

15 Nov '11

Hi! I see there's broad support for the 2011-05 proposal - by an overwhelming majority of IXP people... There also seems to be broad support for the 2011-04 proposal - I can't really say for sure, but probably by an overwhelming majority of 6RD people... So my 2 cent as some non-IXP non-6RD guy: - I think IXPs should get the IPs they need. That is, just like everyone else. No special treatment. So in 2011-05's sense: 'no'. - I think people who want to use 6RD should get the IPs they need (that includes space for a reasonable 'decent setup' not just the 'minimum space to make it work'). That is, just like everyone else. No special treatment. As 2011-04 doesn't treat 6RD special, that would be ok in this sense - but also superfluous. If $organisation submits documentation reasonably justifying the need for a /29 (like "we do 6RD"), I don't see where the current version of 5.1.2 doesn't already allow what 2011-04 wants to achieve. That's why I'd say 'no' to 2011-04 while at the same time I'd appreciate giving /29 to people who need it for their 6RD setup. Also, I believe 5.2 already allows the same (/29 for 6RD), and I see no need to add a specific paragraph under 5.1 (while I think there might be potential (but not necessarily a need, imho) to make 5.2 more defined and concise). - I am totally a fan of KISS (errm - and btw I expand that to "...small and simple", not "...simple, stupid" ;), and this explicitly and specifically includes policies. I'd therefore generally abstain from putting more specific cases or redundancy than absolutely necessary into policy. In the thread up to now, I didn't see anything that made it clear to me why making IXPs (and/or 6RD) special cases is necessary (or even legitimate). There have been arguments as to lots of IXPs are noncommercial, commercial and noncommercial IXPs cannot be distinguished from each other, and they're all 'good', so they all should be special. I think that's wrong in every way: most IXPs are commercial, it's easy to identify whether an IXP is commercial or noncommercial (on the given examples to illustrate how difficult it is: these three were clearly all commercial), and 'IXPs are good for everybody' is not much different to saying 'starting work at 6am is good for everybody'. Let's not start making some things more equal than others. Well and in case somebody wants to fill up the 'Arguments opposing' paragraph - wouldn't be wrong, I'd say... Following the same rationale, on Gert's concept on "IPs are IPs, IP users are IP users.": while true; do echo -n +; done I really like this! (Except maybe for the 'special case' range - I'd suggest to just skip that, too. Better let's just say "Every IP is special."... There was an example mentioned like $usual_suspect wants another /2, as they do regularly, and as $rir hasn't got sufficient insight into their net design, they just get it. This might be a bit exaggerated ;) - but I think it describes a major existing problem, which really needs to be addressed. In the end it reads to me: The request isn't sufficiently justified. It just shouldn't be approved, in this case - until justified. A huge part of the address space (v4) obviously suffered this kind of problem since ages - and on the so called IPv4-depletion: just by 'cleaning up' some of the existing insane allocations, the 'problem' would disintegrate into thin air (and it might be used as another means to promote v6, btw). I even consider this a moral obligation for anything assuming the role of coordinating the IP commons. I believe we have a really pressing issue here. Regards, Chris

1 0