Hi Ahmed,
Do I understand correctly that you are actually saying that an organization should base its IPv6 addressing scheme upon its existing (legacy) IPv4 addressing scheme? As this seems to me what one would actually do if you drop native IPv6/ dual-stack implementation “in favor” of 6rd… If this is what you are pointing at, I really have to disagree as I don’t believe this is the way to go. IPv6 is different from IPv4 and so a different addressing plan makes sense. So let us give an organization the possibility to do its IPv6 address assignments right from the beginning and let’s not force them to get stuck in transition methods (as this will convert them into anti-transition mechanisms as suggested in a previous message in this thread).
Regarding your other remarks/ suggestions:
1. I do agree 6rd has its limitations, but on the other hand, an organization might have some perfect good reasons to prefer 6rd above another transition protocol (for instance because it is – in contrary to other transition protocols – fully supported by both the CPE devices as well as the ISP’s edge routers).
2. What I actually mean with native IPv6 is dual stack with the IPv6 stack “free of tunnels” (sorry for the confusion). I do realize we cannot neglect the fact IPv4 will be around for a while and thus still needs native support as well.
Regards,
Kurt
From: Ahmed Abu-Abed [mailto:ahmed@tamkien.com]
Sent: maandag 28 februari 2011 13:45
To: Kurt Smolderen; address-policy-wg@ripe.net
Subject: Re: [address-policy-wg] IPv6 allocations for 6RD
Hi Kurt,
If you implement 6RD then an internal network can use multiple /64s, with each /64 coming from one of the few IPv4 public addresses such an internal network uses. And all this happens under one /32 assignment.
Note that the /64 limitation is specific to 6RD protocol as I explained in an earlier email. Other transition protocols may not have this limitation.
As for native IPv6 deployment, if you mean IPv6-only (i.e. not Dual-Stack) then I doubt it has much use for the coming few years as much of the content and applications are IPv4-only. New translation protocols, to enable IPv6-only host reaching IPv4 content, are being developed but they have their limitations.
Even deploying Dual-Stack (DS) end-to-end, without tunneling, is not enough. The logic behind this is content will still be mostly IPv4 for years to come, while public IPv4 addresses are in very short supply. Thus one is forced to use private IPv4 addresses for end users, but these are not routable. The solution is then to tunnel the private IPv4 in public IPv6 addresses, hence DS-Lite protocol. But this assumes you have a full Dual-Stack deployment end-to-end; if not then you need to overlay IPv6 over IPv4 using 6RD, TSP or L2TP as an interim solution.
Regards,
-Ahmed
From: Kurt Smolderen
Sent: Monday, February 28, 2011 11:13 AM
Subject: RE: [address-policy-wg] IPv6 allocations for 6RD
I strongly support the idea of assigning a smaller prefix to ISPs which are in a state of deploying IPv6 but need to use transitional mechanism for (some of) their customers. Mark has described one of the problems very clear in his email: if an ISP has only a /32 prefix and needs to use all 32 IPv4 bits in the 6rd configuration, only a /64 can be delivered to the home instead of the desired /56 or /48. Needing all 32 bits is for instance the case when an ISP offers internet connectivity to some of its customers via a partnership with another ISP.
However, I want to point to an additional problem which appears when an ISP wants to deploy native IPv6 but needs to roll out 6rd (or any other transitional technique) as well. For native IPv6, the ISP will create an IPv6 addressing plan. This will normally include separate prefixes for the ISP's own servers, the ISP's backbone, the ISP's customers etc. For the 6rd domain, the full /32 range is however needed. So at this stage, the ISP has two options:
1) Implement 6rd only
2) Implement native IPv6 only and exclude some customers from being able to use IPv6 (those which would normally be connected through 6rd)
I strongly believe we all agree 6rd is only a temporary solution. So I can't imagine we would prefer skipping native IPv6 deployments in favor of IPv6 transitional mechanisms.
I also believe we all agree we should enable IPv6 for as much customers as we can, which makes me conclude the second 'option' is not really an option at all...
My primary concern is that any ISP - regardless of how small or big it is - can independently of other organizations/ ISPs move forward with IPv6 deployment. RIPE can support this by adapting a policy which - albeit for a limited time span - allows the assignment of a contiguous IPv6 prefix which size does not only depend on the amount of customers the ISP has, but also incorporates the needed technologies to 'IPv6-enable' as much customers as possible.
Regards,
-Kurt