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@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@ripe.net Message-ID: <4EA5BC6F.90005@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
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
participants (2)
-
Ahmed Abu-Abed -
Jan Zorz ＠ go6.si