This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD
- Previous message (by thread): [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD
- Next message (by thread): [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ahmed Abu-Abed
ahmed at tamkien.com
Thu Feb 24 15:43:57 CET 2011
HI Géza, Given IPv4's imminent depletion at the RIR level, dual-stacking without tunneling or translation will be a short term solution too. Pure dual-stacking, up to the consumer's premise, assumes you are laying out dual-stack (with both IPv4 and IPv6 enabled) nodes from core up to the CPE, and the customer is getting both IPv6 and IPv4 public addresses, and the latter is very scarce. So for v4 and v6 to coexist for the next 10 years or so we need tunneling, or some form of IPv6-only at the customers terminal with translation to IPv4 if needed. Hence my /32 endorsement for all IPv6 access methods. Regards, -Ahmed From: Turchanyi Geza Sent: Thursday, February 24, 2011 4:25 PM To: Ahmed Abu-Abed ; address-policy-wg at ripe.net Cc: Wyatt Mattias Gyllenvarg Subject: Re: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD Hello Ahmed, Many thanks for forwarding the comparison table. Temporary solutions are usefull in the transition phase. However, I would prefere emphasize even in the address allocation mechanism if a solution is temporary and should go away in long term. Therefore I fully agree with János, the smallest address space the best in case of 6RD and other non-real-dual-stack method. Géza On Thu, Feb 24, 2011 at 2:48 PM, Ahmed Abu-Abed <ahmed at tamkien.com> wrote: Hello, I am new to the Address Policy WG and this seems like quite an old discussion. I endorse assigning a /32 to LIRs regardless of the IPv6 access method they use. Other than to 6RD, TSP is another protocol (RFC 5572) that can be used to enable IPv6 to end users rapidly over intermediate IPv4 nodes. A useful comparison between TSP, 6RD and other IPv6 access tunneling protocols is shown in http://gogoware.gogo6.com/4105/file.asp?file_id=942 As for IPv6 CPE and server gateways availability, there are commercial solutions in the market that implement 6RD and TSP for both sides of the tunnel. Regards, -Ahmed From: Wyatt Mattias Gyllenvarg Sent: Wednesday, February 23, 2011 5:24 PM To: address-policy-wg at ripe.net Subject: RE: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD Hi We would like to weigh in here. We feel that it should be RIPEs policy to allocate ONE /32 to any LIR who requests it for 6rd. 6rd is the only way for us to reach all our residential customers. Especially those in Municipal Networks that are very slow to invest in their networks and often do not have the competence and time to impelment IPv6. Also, Cisco has not yet implemented even a small part of the protective mechanisms we rely on in IPv4 to secure our residential networks. Many of these features are required to meet the demands contracted with the customers. We cannot use native IPv6 until Cisco implements these features and we have tested and rolled them out on hundreds of switches. 6rd bypasses all these issues. IF we can get a /32 for that purpuse. -- Med Vänliga Hälsningar - Best regards Mattias Gyllenvarg Network Operations Center Bredband2 ---------------------- end of line --------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/address-policy-wg/attachments/20110224/fc590110/attachment.html>
- Previous message (by thread): [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD
- Next message (by thread): [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]