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

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

Update in the Policy Proposal Archive for Proposal 2009-01, "Global Policy for Allocation of IPv4 blocks to Regional Internet Registries"
by Emilio Madaio 15 Nov '11

15 Nov '11

Dear colleagues, As announced at RIPE 63, we will add an explanatory note to the status of policy proposal 2009-01 "Global Policy for Allocation of IPv4 blocks to Regional Internet Registries", as approved by the RIPE community in August 2010. The note reads: "In October 2010, ICANN announced that the NRO deemed the global policy proposal abandoned due to differences in the global proposal texts among the RIRs. This proposal, although regionally accepted, will never be globally implemented." The ICANN announcement is available at: http://www.icann.org/en/announcements/announcement-12may09-en.htm An archive of all RIPE policy proposals is available at: http://www.ripe.net/ripe/policies/archived-policy-proposals Kind regards, Emilio Madaio Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] Status of 2011-02 Policy Proposal Removal of multihomed requirement for IPv6)?
by Dan Luedtke 10 Nov '11

10 Nov '11

On Wed, Nov 9, 2011 at 10:28 AM, Turchanyi Geza <turchanyi.geza(a)gmail.com> wrote: > 1, Most of the content must be accessible on IPv6 stack as well; > 2, Broadband users must be supported. Never questioned that. But, that is no reason to stay in the way of those who *want* to deploy IPv6 but cannot get their hands on addresses. It is just not ok, that a RIPE policy is preventing deployment in some networks while we are pushing large ISP to deploy it. We should push *all* parties to deploy it. It's not only the ISPs internet, although they are a/the force of it. As I understood, the other RIRs have not encountered a pollution problem when allowing PI assignments without multihome-requirement. But I may be wrong on this, as I have no numbers were I am right now. regards, Dan -- Dan Luedtke http://www.danrl.de

1 0

Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)?
by DI. Thomas Schallar 09 Nov '11

09 Nov '11

Hello! What ist the current status on the multihomed v6 PI topic? regards, Thomas

32 70

Re: [address-policy-wg] Status of 2011-02 Policy Proposal Removal of multihomed requirement for IPv6)?
by Albert Siersema 09 Nov '11

09 Nov '11

Geza, > I do see it differently. PI address space is easy to use, however, this > allocation mechanism does not scale. Therefore was invented CIDR and PA > allocation, if you do remember... Could you eleborate on "does not scale" ? When deploying IPv6 one should set aside an IPv4 mindset. The same goes for the whole rehashing of the "does not scale" issue. You can't expect early 90's routing hardware to do the job of current BGP Internet routing. And when everyone will be running IPv6 (not tomorrow), the current limits for hardware won't apply. Let's not go into a discussion on asics / 64-core cpu's, but I'm pretty certain that hardware including tcams etc will keep up if the market demands it. Maybe you're referring to something altogether different, that's why I ask. I fully concur with Thomas on this point: for all the IPv4 PI allocations out there it should be possible to get an IPv6 allocation as well. Indeed nothing has changed with regard to the reasons for applying and being granted PI space. The current policy kind of suggests that everyone with IPv4 PI space should just quit their business and hand it over to the LIR as they are the only ones getting PI space for customer traffic. Regards, Albert > Turchanyi Geza schrieb am 07.11.2011 10:02: > nothing stops th IPv4 PI owners to use IPv6 PA.... > > > Nothing stops anybody of using PA, neither in IPv4 nor in v6. That's not > the question. > > But any reasons, why somebody wants/needs IPv4 PI space will usually fully > apply to IPv6 also. It would seem stupid to me, to have IPv4 ("the past") > as PI but IPv6 ("the future") as PA. That won't make sense. What changed > between my v4 PI application and my v6 PI application? If I won't need PI > on v6 any more, I probably won't need it on v4 any longer. > > Siple question: do I need my machines to have provider independend IP > addresses or not? If yes, then I need *ANY* address (IPv4, IPv6, > IPvSomething) to be PI and not PA. > > So, if somebody already has IPv4 PI space, he/she should more or less > automatically receive v6 PI under the same conditions as for v4. He/she > just has to reason, why some default /48 won't be enough. Thats my opinion. > > regards, > Thomas

7 8

Re: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation)
by Anfinsen, Ragnar 09 Nov '11

09 Nov '11

Late, but anyway. We support this proposal. MVH/Regards Ragnar > -----Opprinnelig melding----- > Fra: address-policy-wg-bounces(a)ripe.net [mailto:address-policy-wg- > bounces(a)ripe.net] På vegne av Emilio Madaio > Sendt: 21. oktober 2011 12:45 > Til: policy-announce(a)ripe.net > Kopi: address-policy-wg(a)ripe.net > Emne: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the > Minimum Size for IPv6 Initial Allocation) > > > Dear Colleagues, > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > www.ripe.net/ripe/policies/proposals/2011-04 > > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 18 November 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC >

4 4

6rd as technology that might have an impact to HD ratio
by Jan Zorz ＠ go6.si 05 Nov '11

05 Nov '11

Hi, During last week the question was risen "what do we do, if we get /29, assign /30 for 6rd, use /30 for native part of deployment, then we fill it up and need additional allocation? Is 6RD /30 assignment valid as a whole in HD ratio game?" Well, my thoughts on this are: 1. If you filled up the whole /30, then you should probably not be running 6RD anymore, get rid of it and use that space for native 2. If you filled up /30 and can't get rid of 6RD, evaluate again you addressing plan sanity :) 3. If nothing of the above does apply, you are probably so big you should get more than /29 as initial allocation anyway 4. What else can possibly go wrong? So, 6RD should not be treated as anything special, as it is not a part of modified text in the policy, therefore if you are running 6RD, you still need to show the number of sites that you are covering with IPv6 PD and this has really nothing to do with 2011-04 proposal (but I can see new HD ratio discussion in the horizon :) ) I was specifically asked to put this question forward on this mailinglist in order to provide some further guidance for IPRAs, if 2011-04 reaches consensus (hope so :) ) Cheers, Jan

2 1

Re: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation)
by boggits 05 Nov '11

05 Nov '11

On 21 October 2011 11:44, Emilio Madaio <emadaio(a)ripe.net> wrote: > www.ripe.net/ripe/policies/proposals/2011-04 Okay, I can see the logic, but please can we not do this :) I'm all for allowing a policy that says LIR can request a /29 rather than a /32 and that deploying 6rd is a valid reason for allocating a /29 as an initial block but can we do this by having the LIR send the documentation in and having it reviewed for logic. J -- James Blessing 07989 039 476

15 41

Re: [address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation)
by Daniel Holme 02 Nov '11

02 Nov '11

On 21 October 2011 12:44, Emilio Madaio <emadaio(a)ripe.net> wrote: > www.ripe.net/ripe/policies/proposals/2011-04 > > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 18 November 2011. Hi On the premises that there are no protocol specific comments in the policy then I support this proposal too. This should be a matter of address assignment policy only. Based on a mixture of /56 and /48 assignments to users it's easily possible for a medium to large ISP to need more than a /32. Also, increasing allocation sizes can only do good things for the IPv6 DFZ. -- Daniel Holme

1 0

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

02 Nov '11

On Tue, Oct 25, 2011 at 11:51:26AM +0200, Emilio Madaio wrote: > > http://www.ripe.net/ripe/policies/proposals/2011-05 > I, too, support this proposal (Disclosure: We operate an IXP) Kind Regards, Sascha Luck

1 0

2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Kjetil Otter Olsen 02 Nov '11

02 Nov '11

We (Norwegian Internet eXchange) support this proposal. Best regards, Kjetil Otter Olsen, NIX.no

1 0

concept document: IPv6 PA/PI unification
by Gert Doering 01 Nov '11

01 Nov '11

Hi AP WG, next week at the RIPE meeting (and by remote participation, of course) I want to continue discussing an idea that came up before, and that I brought up at RIPE 62 already - doing away with the distinction between IPv6 PA and IPv6 PI space, going for a "unified number distribution policy" (to give credits, it's not exactly my original idea, but has been brought up a couple of times by members of the community in the last years). Feedback from RIPE 62 was mostly positive, with "we need to think about many details", so Sander and I sat down and tried to write a concept document that has some answers about the details - which needs to be discussed, refined, and eventually formed into a full-featured policy proposal to go through the PDP. So far, this is to start the thought process, and to get your ideas about it - especially ideas of the sort "this is not going to work *because* <detail we've overlooked>". But I'm taking "we want to keep the difference between PA and PI!" as well - but if you say so, please explain where you see the benefit of "more complicated rules". The discussion will take place on Thursday morning, in the 09:00-10:30 time slot. thanks for helping shape policy, Gert Doering -- APWG chair --------------------------------------------------------------- Motivation: why? ---------------- - PA and PI are just different labels for "IPv6 addresses" ... but with different strings attached: - PI must not be used for 3rd party assignments (problem for hosting providers) - only single PA allocation for LIRs possible, even if multiple independent networks exist - network structure and operation is very different these days than at the time where the PA/PI distinction was made. The boundaries between networks, different operators and different services are not as clear as they used to be... - the classic distinction "PA is for ISPs and their access customers" "PI is for enterprises that do not do ISP-like business" has been overcome by reality, and there are no longer clear borders between "ISP", "enterprise" and "end-customer" networks - Network addresses are for *numbering network devices*. Limiting what someone is allowed to do with certain addresses creates confusion. Constantly having to tweak policy to work around this is the wrong solution. Goals and Caveats ----------------- - encourage IPv6 deployment - be flexible enough to accommodate both typical and non-typical network- and business models - do not encourage assignment of /64 or single addresses to end users - do not encourage excessive routing table growth - encourage proper documentation and discourage lying to the RIPE NCC to wiggle around policy restrictions The Proposal ------------ - abandon distinction between PA (allocation) and PI (assignment) - everything is just "numbers" - RIPE NCC hands out "block(s) of numbers" to "users of numbers" - see below for answers on the fine print... Who get's address space? ------------------------ - existing model is kept: LIRs as distribution point for address space - either to "the LIR organization" - classic model: "LIR is part of the Internet Provider business" - or via the LIR to "the entity that wants to use the space and take responsibility for it" (sponsoring LIR), keeping the contractual requirements of 2007-01 - "Direct Assignment Users" members could still be possible, but "every NCC member is an LIR" would simplify things further (see "Costs" section) Amount of space per "block of numbers"? --------------------------------------- - /48 (or larger with justification) by default - /32.../29 (or larger with justification) allowed when planning to assign to 3rd parties - multiple "blocks of numbers" to or via a single LIR allowed and expected to be a frequently seen usage case Allocation from well-known ranges for anything that people might want to treat specially in their routing policy (former "special case" and PI policies): - IXP - Root DNS - Anycast DNS - /33.../48 blocks Cost? ----- - determined by AGM, but we can discuss models here and provide recommendations to AGM and NCC board, e.g.: * base cost per year per LIR * yearly recurring cost "per block of numbers", independent of size(!), reflecting the cost of handling the address space request, documentation, RIPE database, etc., which increase if you need "many blocks" Multiple blocks per LIR? ------------------------ - since there would no longer be any difference between PA and PI, "more than one block going to a single LIR" would be a typical case - so it needs to be permitted - "get any number of blocks that people are asking for" is not likely to get consensus due to pressure on the routing system - proposal for compromise: ``one "block of numbers" per "network"'' - needs workable definition for "network": - interconnected network - operated by the same entity - operated as a layer 3 network - be flexible in allowing multiple blocks, but don't *require* anyone to actually ask for multiple number blocks if they are happy with using the same address block for multiple networks/sites/... - problem cases to keep in mind, leading to this definition - ISPs providing L3 services on top of other ISPs' Layer 2 infrastructure - single LIRs providing addresses to two independent Layer 3 networks that are not directly connected - e.g. due to political (commercial/NREN), legal or geographical reasons - "classical PI" type connections - end users with independent numbers - Multiple L3 providers providing address space to a single user must be allowed (multi-homing, special-purpose networks, etc.) -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

4 7

Re: [address-policy-wg] 2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Daniel Holme 01 Nov '11

01 Nov '11

On 25 October 2011 11: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. > http://www.ripe.net/ripe/policies/proposals/2011-05 Hi I support this proposal. -- Daniel Holme Kcom

1 0

2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Rolf Schärer 01 Nov '11

01 Nov '11

+1 I support the proposal Cheers, Rolf ------------------------------------------------------------------------------- netspring gmbh rolf schärer, ccie #17218 alte gasse 4 rolf.schaerer(a)netspring.ch 8610 uster, switzerland Tel: +41 44 500 79 70

1 0

2011-05 New Policy Proposal (Safeguarding future IXPs with IPv4 space)
by Basile Bluntschli 01 Nov '11

01 Nov '11

+1 i support the proposal -- s w i s s i x - Swiss Internet Exchange Basile Bluntschli Board Member

1 0

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

31 Oct '11

* Emilio Madaio: > http://www.ripe.net/ripe/policies/proposals/2011-05 I oppose this policy. IXPs shouldn't be special-cased. The assumption of a single peering LAN per organization does not seem to match the requirements of the industry. It is odd that preexisting PI space must be returned, but not existing PA space. -- Florian Weimer <fweimer(a)bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99

2 1

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