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

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Sascha Lenz 31 Oct '11

31 Oct '11

Hi, Am 25.10.2011 um 11:51 schrieb Emilio Madaio: > > > Dear Colleagues, > > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. > > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-05 > > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 22 November 2011. i'm not a fan of "special entities", but IXPs actually are a bit special and the proposal again makes some examples why, so i do support this proposal. Reserving an(other) /16 for this purpose doesn't really hurt anyone either. I am not quite sure if 180days for returning the old prefix is really enough in a world where it's hard to reach some peering partners and get reactions in under 360days :-) but i'm not an IXP operator so what do i know... I just assume it's reasonable? -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect

2 1

Re: [address-policy-wg] 2011-04 New Policy Proposal
by Ahmed Abu-Abed 28 Oct '11

28 Oct '11

In reality RIPE will be giving up a finite resource for implementing one particular type of a transition protocol, i.e. 6rd. Can't the response be go back to your vendor and ask them to implement a different transition protocol that doesn't waste address space ? After all, there are many such protocols out there. -Ahmed Date: Tue, 25 Oct 2011 11:04:20 +0200 From: "Jan Zorz @ go6.si" <jan(a)go6.si> Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal To: address-policy-wg(a)ripe.net Message-ID: <4EA67B94.2090305(a)go6.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 10/25/11 9:44 AM, Ahmed Abu-Abed wrote: > Interesting to see a v6-in-v4 access protocol triggering a significant > change in allocation policy. > > As 6rd gobbles up 32 bits for the v4 address at the consumers v6 > assignment, there is an alternative in RFC 5572 (TSP) that presents > v6-in-v4 access on CPEs without such a need. And TSP can be implemented > as a software client so LIRs do not need to change the CPEs to roll out > IPv6 to end users. Dear Ahmed, We are aware of many similar technologies that would fulfill the same or similar goal, but what we are doing here is just listen to complains and requests from the field and try to make deployment of IPv6 (native or as service in this case) as easy as possible with this change of the policy proposal. Reality usually wins :) Cheers, Jan -------------------------------------------------- From: "Ahmed Abu-Abed" <ahmed(a)tamkien.com> Sent: Tuesday, October 25, 2011 9:44 AM To: "RIPE Address Policy" <address-policy-wg(a)ripe.net> Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal > Interesting to see a v6-in-v4 access protocol triggering a significant > change in allocation policy. > > As 6rd gobbles up 32 bits for the v4 address at the consumers v6 > assignment, there is an alternative in RFC 5572 (TSP) that presents > v6-in-v4 access on CPEs without such a need. And TSP can be implemented as > a software client so LIRs do not need to change the CPEs to roll out IPv6 > to end users. > > -Ahmed > > ------------------------------ > > Message: 8 > Date: Mon, 24 Oct 2011 21:28:47 +0200 > From: "Jan Zorz @ go6.si" <jan(a)go6.si> > Subject: Re: [address-policy-wg] 2011-04 New Policy Proposal > (Extension of the Minimum Size for IPv6 Initial Allocation) > To: address-policy-wg(a)ripe.net > Message-ID: <4EA5BC6F.90005(a)go6.si> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/24/11 7:29 PM, Randy Bush wrote: >> why are we screwing around? let's go straight to a /16 or at least a >> /20. > > it would not be fair to legacy v6 allocations :) > > can only expand to /29 without renumbering :S > > cheers, Jan >

7 9

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Tom Bird 28 Oct '11

28 Oct '11

On 25/10/11 10:51, Emilio Madaio wrote: > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-05 Morning, I support this proposal. -- Tom Bird Director, http://www.portfast.co.uk/ : AS8916 UK Limited company #6061075 : +44 1777 29 28 27

6 6

Re: [address-policy-wg] [policy-announce] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by David Croft 28 Oct '11

28 Oct '11

On 25 October 2011 10:51, Emilio Madaio <emadaio(a)ripe.net> wrote: > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. I support this proposal as written. Regards, David Croft

1 0

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Andy Davidson 28 Oct '11

28 Oct '11

> You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-05 I support this proposal. -harald > > We encourage you to review this proposal and send your comments to > <address-policy-wg at ripe.net> before 22 November 2011. -- Harald Michl <harald.michl(a)univie.ac.at> Vienna University - ACOnet www.ACO.net - VIX www.VIX.at Universitaetsstrasse 7, A-1010 Vienna, Austria, Europe Tel: +43 1 4277 - 14078 (Fax: - 9140) HM3550-RIPE

3 2

Removal of multihomed requirement for IPv6 PI ?
by DI. Thomas Schallar 28 Oct '11

28 Oct '11

Hello! Four days ago the current phase on http://www.ripe.net/ripe/policies/proposals/2011-02 ended (Sep.26th-Oct.24th). What now? regards, Thomas

2 1

2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Steven Bakker 28 Oct '11

28 Oct '11

Just piping in to say I support this proposal. -- Steven

1 0

2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Michiel Appelman 28 Oct '11

28 Oct '11

I fully support the new policy proposal. -- Michiel Appelman AMS-IX

1 0

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Nigel Titley 27 Oct '11

27 Oct '11

On 25/10/2011 10:51, Emilio Madaio wrote: > Dear Colleagues, > > A proposed change to RIPE Document ripe-530, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. > I hate to be a killjoy here, but doesn't the average IXP use less than a /22? Part of the rational says: "Much of the work that goes into creating Internet Exchange Points today is done in regions of the world where there is no Internet Exchange Point yet. Opening an IXP helps to develop the Internet and Internet community in that region, so the work really is 'good of the Internet'. Starving these regions of an opportunity to build a simple open Internet Exchange Point would be severely damaging to Internet users in regions under-served by IXPs." But a brand new IXP will be able to get a /22 under the existing rules. Surely that's enough? I have a general dislike of "special cases" especially where they don't seem to be necessary. And this seems to be unnecessary. Nigel

3 7

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Barry O'Donovan 27 Oct '11

27 Oct '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/10/11 10:51, Emilio Madaio wrote: > A proposed change to RIPE Document ripe-530, "IPv4 Address > Allocation and Assignment Policies for the RIPE NCC Service > Region", is now available for discussion. We support this policy. - Barry - -- Kind regards, Barry O'Donovan http://www.opensolutions.ie/ Open Source Solutions Ltd Lynx House, Old Church Road, Lower Kilmacud Road, Stillorgan, Co. Dublin. Open Source Solutions Limited is a company registered in the Republic of Ireland (#438231). Open Source Solutions Limited trades as Open Solutions (registered business name #329120). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ppK0ACgkQ9qwC7To4L8xItACdEfwnvF3KijY7um0Pba0/VfsQ ly0An1TO9dfQfDjKm9TCDt4kexwS589H =uiRD -----END PGP SIGNATURE-----

1 0