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@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@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@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 ---------------------------

On Thu, 24 Feb 2011, Gert Doering wrote:

Hi,

On Thu, Feb 24, 2011 at 03:48:05PM +0200, Ahmed Abu-Abed wrote:

...

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.

Uh, what exactly are we discussing here?

Just to make this very clear:

Any RIPE LIR can get a /32 IPv6 PA right away, just by asking.

Only if you want *multiple* /32, or "bigger than a /32", this is where it gets tricky (multiple distinct /32s are not possible under the current policy, "bigger than a /32" needs documentation that you have the necessary amount of customers).

Gert Doering -- APWG chair

Yes Agreed. I am against the idea, that 6RD deployment automatically grant another /32 allocation. Best Regards, Janos

We agree with Mark on every point. This is the reality we work with. I would accept a time frame for last implementaion and also a time frame for when native6 has to be operational. Med Vänliga Hälsningar - Best regards Mattias Gyllenvarg Network Operations Center Bredband2 ---------------------- end of line --------------------------- On 2011-02-25 16:31, Mark Townsley wrote:

This is not the first time this has come up on this list. It came up a few months back at ARIN as well, and resulted in a policy change that now allows subsequent allocations to ISPs that already have begun deployment within a /32 allocated in the past, but need additional space for continued deployment (for whatever reason, of which 6rd was one of the motivational factors presented). ARIN rejected mention of 6rd specifically as there were understandable objections to mentioning one particular transition technology over another, but it was certainly present in the open discussion leading up to the change.

But, regardless of what ARIN has done, the issues boil down to this:

Native residential IPv6 is proving difficult today. This is particularly problematic for IPoE DSL deployments where the vast majority of equipment deployed in the past 0-5 years which relies on snooping of DHCP, ARP, IMGP, etc. in order to operate in a split-horizon mode with subscribers connected into the same VLAN has largely no support for IPv6, DHCPv6, Neighbor Discovery, MLD, etc. Ironically, architectures based on "last-generation" PPP or simpler 1:1 VLAN models tend to work much better with IPv6 than the latest-greatest architectures that were built up in the past decade. This is true not only in DSL, but throughout the industry as somewhere after the dot-com boom and before the recent realization of IPv4 address exhaustion, much of the industry forgot to keep IPv6 in mind while inventing lots of new stuff. As such, overlays are needed, and 6rd is a particularly well-suited one for residential deployments. At the moment, 6rd is responsible for the majority of ISP-supported IPv6 traffic on the Internet today (based verbal comments from a very large content provider that supports v6), and based on the number of SPs I see successfully turning up 6rd vs. native service, I expect this will continue to be the case for at least the next few years.

With a /32, 6rd easily supports a single /64 to a site. 6rd includes the ability to be more efficient with the address mapping algorithm, but this comes with additional overhead in provisioning that the ISP must endure. I know of SPs that have managed to plan for fairly efficient mappings by setting up several 6rd domains. However, others have difficulties in doing so, and at the end of the day mapping a full 32 bits into the IPv6 prefix is *always* simpler and easier.

If an ISP cannot get a prefix shorter than /32 to operate 6rd within, at some point a decision is made between operational complexity of multiple 6rd domains, cost of native IPv6, cost and scalability of stateful tunnels such as TSP or L2TP, all vs. 6rd with a /64 to the customer. What I'm worried about is that the latter will win, and we'll end up with no subnets in the home. A /64 IPv6 service seriously complicates the design of IPv6 in home networks that have more than a single LAN (including those that simply have a "home" and "guest" SSID).... unless we just give up and have the CPE NAT IPv6, which is another real possibility if we let /64 become the least common denominator service to the home.

All of this is why I would be in strong support of a policy that would allow a /28 to an ISP that requires 6rd in order to deploy IPv6 to its customer base and actually does so within, say, 6-12 months (the most significant limiting factor outside of the direct control of the ISP would be the CPE itself; ISPs which own their own CPE should have a plan for 6rd in future releases, and those without direct control on the CPE should be able to at least point their customers to a 6rd compatible CPE model if they choose to buy one). This allows an ISP that cannot deploy native IPv6 in the near term to deploy IPv6 with 6rd and still allow at least a /60 to the home, which is far, far, better than /64. It's hard enough to get CPE to do IPv6 correctly, and I would really like to avoid them having to get creative enough to figure out how to do IPv6 with a single /64.

As a sidenote: Medium to Large ISPs in the RIPE region are managing to get the space they need for 6rd under existing policies that allow for planning /48s to all sites. As such, the above would effectively end up being a policy change for "smaller" ISPs. To combat fear that the sum of these small ISPs would exhaust all of our v6 address space, we could draw up requirements to identify blocking factors to native IPv6 or 6rd with multiple domains where the alternative would be either no IPv6 or IPv6 with a /64. I'd even go so far as to give preferential treatment to ISPs that can show they will have to resort to CGN deployment before IPv6 could otherwise be deployed.

I'd rather avoid all that complexity though. I think a policy of allowing a /28 to an ISP that is going to deploy and support IPv6 to their users within a short period of time (with a threat of taking it back if they don't!), is not a bad way to spend our address space over the next few years (which is another time limit we could put on the policy). From what I can see, I think we could get a pretty good IPv6 adoption return on that investment.

- Mark