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