<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=us-ascii"> <META content="MSHTML 6.00.2900.3492" name=GENERATOR></HEAD> <BODY> <DIV> Thank you for the first comments received on 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment).<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p> Please find hereafter some response.<o:p></o:p> From Marcus Stoegbauer: <o:p></o:p> >> For a start: I can't really tell if the new policy text should replace <o:p></o:p> >> the old IPv4 address allocation and assignment policy. The new policy <o:p></o:p> >> only talks about address space given out to ISPs for transition <o:p></o:p> >> techniques, so I assume that an ISP with a lot of free (i.e. not<o:p></o:p> >>assigned/unused) IPv4 address space can also get another allocation <o:p></o:p> >>under this policy?<o:p></o:p> <o:p> </o:p> Response<o:p></o:p> This policy is done in accordance with existing v4 policies and basic principle is that allocation/assignment should be based on needs. The difference with that policy is the minimum allocation/assignment size is different and filtering policies, should be different in this range.<o:p></o:p> So when requesting additional IPv4 resources (after the IPv4 pool is depleted - from the transition /8) an ISP should still demonstrate the required utilisation of already allocated addresses.<o:p></o:p> If an ISP has already sufficient resources allocated for implementing <o:p></o:p> transition techniques it should not be qualified to receive additional <o:p></o:p> resources from that policy, except if the use of these resources <o:p></o:p> implies fragmentation and filtering issues.<o:p></o:p> This is to be evaluated by the RIPE-NCC when analysing the request.<o:p></o:p> <o:p> </o:p> From Marcus Stoegbauer: <o:p></o:p> > >Then the minimum size of /27. Obviously it would be a brilliant test <o:p></o:p> >> to see if routers will be able to hold all the IPv6 PI prefixes that <o:p></o:p> >> will come to life once we allow them to be handed out. And it would be <o:p></o:p> > >a very handy way to tear down the v4 internet, so it's in full <o:p></o:p> >> compliance with some IPv6 implementation plans.<o:p></o:p> >> But to be serious for a minute: if all those /27 would be announced a<o:p></o:p> > >IPv4 full table would nearly triple in size (or in other words: all <o:p></o:p> > >those /27 are twice the size of a full IPv4 table today). This can't <o:p></o:p> >> possibly end well, so I'm not in favor for this proposal in its <o:p></o:p> >> current form.<o:p></o:p> <o:p> </o:p> <o:p></o:p> Response <o:p></o:p> I don't think this policy will really change the size of routing table.<o:p></o:p> If the policy is based on a /24 it would only waste v4 resources, and <o:p></o:p> reduce on medium long term the possibility to provide those necessary <o:p></o:p> resources.<o:p></o:p> <o:p> </o:p> The growth of the routing table will be proportional to the growth of the number of new ISPs - PA holders and the use of multi-homing, exactly as today, this proposal will not change this significantly. Please note that a /27 under this proposal will actually represent a today's /21 ( or even shorter prefix).<o:p></o:p> <o:p> </o:p> <o:p> </o:p> >From Sebastian Wiesinger [ripe+apwg@karotte.org]<o:p></o:p> <o:p> </o:p> >> First: It won't work. Most people I know filter prefixes smaller than<o:p></o:p> >> /24 in the DFZ. They will not see these allocations. You can't assume <o:p></o:p> >> that they will change their filters for this. I would estimate that <o:p></o:p> >> most of them won't. Many can't do this because it will not fit in <o:p></o:p> >> their RIB/FIB. So if you do this you would have to give out a /24 at least.<o:p></o:p> <o:p> </o:p> Response: <o:p></o:p> It won't work in the current situation but will have to work in the new depleted context. Rather than splitting the existing v4 resources <o:p></o:p> in small pieces, the proposal suggests to dedicate a specific /8 where <o:p></o:p> filtering policies could be adapted.<o:p></o:p> <o:p> </o:p> From Sebastian Wiesinger [ripe+apwg@karotte.org]<o:p></o:p> >> Second: We do want to facilitate deployment of IPv6. I think this <o:p></o:p> >> proposal could be counterproductive. You're splitting up the remaining <o:p></o:p> >> space in smaller peaces so that more people can use IPv4 for a longer <o:p></o:p> >> timespan. And if you have to give out /24s you can bet that people <o:p></o:p> >> will use it for other things besides NAT-PT etc.<o:p></o:p> <o:p> </o:p> Response:<o:p></o:p> No we don't want to prolong v4 lifetime, only to allow for v6 <o:p></o:p> providers to interact with the existing v4 environment that will not <o:p></o:p> disappear overnight. This proposal will not in my views prolong v4.<o:p></o:p> Whether we want this or not, the demand for IPv4 address space after the<o:p></o:p> IPv4 pool is depleted will continue. It will be proportional to the amount of existing IPv4-only resources and the number of newly connected customers, regardless whether they are IPv4 or IPv6-only, or dual-stack.<o:p></o:p> This proposal attempts to satisfy this demand on continuous and predictable basis for the transition period without changing the fundamental principles of resource allocation.<o:p></o:p> <o:p> </o:p> From Sebastian Wiesinger [ripe+apwg@karotte.org]<o:p></o:p> > Third: Is it necessary? You already have to demonstrate a need for <o:p></o:p> > address space if you want a new allocation. If an LIR already has an <o:p></o:p> > allocation I assume that they can spare an /27 for IPv6 transition.<o:p></o:p> >> If you have a new LIR you allocate them a /21 if they can demonstrate <o:p></o:p> > the need for it, no change there.<o:p></o:p> <o:p> </o:p> Response: <o:p></o:p> I say YES it is necessary because remember we are in a depleted context.<o:p></o:p> It means that the RIPE-NCC will not be in a position to allocate IPv4 <o:p></o:p> addresses under today policies. Are you totally sure that all existing <o:p></o:p> holders of IPv4 resources will be able to spare /27 for IPv6 transition?<o:p></o:p> <o:p> </o:p> And regarding new entrants where those /21 will come from? I think we <o:p></o:p> cannot deny that exhaustion is becoming a reality.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> From Andy Davidson<o:p></o:p> >> If it's good to restrict the allocation and assignment of v4 resources <o:p></o:p> >> to organisations who have a stated v6 deployment policy, then why do <o:p></o:p> >> we need to wait until the final /8 has been allocated to the NCC <o:p></o:p> >> before we begin such a policy ? Perhaps we should have a phased <o:p></o:p> >> process that asks organisations how they are deploying v6 on the PA <o:p></o:p> >> and PI request forms, and then future requests from that organisation, <o:p></o:p> >> or related organisations are refused if the deployment has not started.<o:p></o:p> <o:p> </o:p> Good point Andy, I am not opposed to think about something that could <o:p></o:p> be inserted in the "run out fairly proposal" opening the way to something<o:p></o:p> stricter on the last /8 policy<o:p></o:p> <o:p> </o:p> From Andy Davidson<o:p></o:p> >>Why was /27 selected rather than /26 or /25 ? Since most deployments <o:p></o:p> >>have multiple, separate infrastructure assignments, and services/user <o:p></o:p> >> assignments, it seems that a /27 as a minimum allocation is far to <o:p></o:p> >> small to promote any degree of aggregation whatsoever. This policy is <o:p></o:p> >> therefore counter to one of RIPE's regularly stated aims - to promote <o:p></o:p> >> route aggregation. The counter argument to this is that I might as <o:p></o:p> > >well accept that we the side of common sense has lost the v4 <o:p></o:p> > >aggregation debate, and v4 after-market sales will drive deagg <o:p></o:p> > >further, so why should we care ?<o:p></o:p> <o:p> </o:p> Response: <o:p></o:p> Remember that we need a mechanism that allows to provide the small <o:p></o:p> amount of IPv4 addresses needed to interact with the IPv4 environment <o:p></o:p> for a long time (before Ipv4 addresses being completely obsolete).A <o:p></o:p> similar approved policy in ARIN is based on a /28!<o:p></o:p> A downscaling factor of 64 is in my view a good compromise. <o:p></o:p> <o:p> </o:p> From Andy Davidson<o:p></o:p> >> On the other hand, perhaps this policy will be seen as an ipv4 life <o:p></o:p> >> extension policy. We do not want to muddy the message that we send to <o:p></o:p> >> the community. V4's free pool will soon be gone. Do not gamble your <o:p></o:p> >> company on policies designed to extend the availability of a very <o:p></o:p> >> scarce resource.<o:p></o:p> >> Maybe we can pool some of the ideas in 2009-03 and -04, and the <o:p></o:p> >> community response, and build a solid run down policy that encourages<o:p></o:p> >>v6 adoption, but doesn't pretend to be able to extend the life of v4.<o:p></o:p> <o:p> </o:p> Response: <o:p></o:p> The intention of the proposal is certainly not to extent the IPv4 life.<o:p></o:p> On the contrary we try to put some incentive for a move to v6 <o:p></o:p> facilitating to those who go that way a fair access to the limited v4 <o:p></o:p> resources strictly needed to interact with the existing v4 environment.<o:p></o:p> <o:p> </o:p> We must be realistic even if we all call for a move to v6 Ipv4 will <o:p></o:p> not disappear overnight and transition to IPv6 requires continuous supply of IPv4. Without this we will face an double or triple NAT and walled garden alternatives which will change the architecture and principles of the Internet significantly and will never get us to IPv6.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Regards <o:p></o:p> Alain<o:p></o:p> </DIV> <DIV> </DIV></BODY></HTML> <table><tr><td bgcolor=#ffffff>********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** </td></tr></table>