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
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.
only problem is that 6rd is not a transition mechanism. it is an anti-transition mechanism. randy
Le 28 févr. 2011 à 10:29, Randy Bush a écrit :
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.
only problem is that 6rd is not a transition mechanism. it is an anti-transition mechanism.
Whatever you call it, it remains an effective way to rapidly offer native IPv6 addresses, and real IPv6 service, to customers. RD
Greetings, Compared to 6RD, the TSP protocol (RFC 5572) can also rapidly deploy IPv6, needing one /32 allocation while customer site prefixes can be /64, /56 or /48. Reason is TSP doesn't embed the customer's IPv4 address in its IPv6 address as 6RD does. Being a hot topic nowadays, its worth mentioning customer site access gear (CPE) requirements are more relaxed with TSP as it doesn't need the Service Provider IPv4-only access modem to be changed or upgraded. A TSP client can run in a small hardware device (thru an Ethernet interface connection) or a software client in the home network behind the SP modem while enabling all v6 capable nodes with the assigned prefix by automatically establishing a tunnel to the SP TSP tunnel server. Since TSP allows for static prefix assignment and larger prefixes than /64 without wasting v6 space, this would mimic a native deployment more closely. The stateful tunneling could be seen as any other encapsulation in the access, and a few service providers have it running already. In the long term, both 6RD and TSP will give way to reverse tunneling i.e. v4-in-v6, as this is the only way (after IPv4 depletion) for both protocols to co-exist on a host while having a mix of v4-only and dual-stack accessible services/website. Reverse tunneling's current protocols, DS-Lite and DSTM, are very similar to TSP's concept so the same clients & servers supporting TSP can be adapted to support DS-Lite. Unfortunately, until IPv4 disappears from web content, hosts and servers these coexistence mechanisms will be needed. Regards, -Ahmed From: Kurt Smolderen Sent: Monday, February 28, 2011 11:13 AM To: address-policy-wg@ripe.net 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
On Feb 28, 2011, at 10:42 AM, Ahmed Abu-Abed wrote:
Greetings,
Compared to 6RD, the TSP protocol (RFC 5572) can also rapidly deploy IPv6, needing one /32 allocation while customer site prefixes can be /64, /56 or /48. Reason is TSP doesn't embed the customer's IPv4 address in its IPv6 address as 6RD does.
TSP is stateful, and thus scales in proportion to the number of subscriber endpoints supported as opposed to simply the number of IPv6 packets transported (e.g., TSP servers will likely have a "per-user" license or at least a per-user scaling limit per box. In contrast, 6rd has no concept of the number of users it is supporting, only the number of packets it is pushing). - Mark
Being a hot topic nowadays, its worth mentioning customer site access gear (CPE) requirements are more relaxed with TSP as it doesn't need the Service Provider IPv4-only access modem to be changed or upgraded. A TSP client can run in a small hardware device (thru an Ethernet interface connection) or a software client in the home network behind the SP modem while enabling all v6 capable nodes with the assigned prefix by automatically establishing a tunnel to the SP TSP tunnel server.
Since TSP allows for static prefix assignment and larger prefixes than /64 without wasting v6 space, this would mimic a native deployment more closely. The stateful tunneling could be seen as any other encapsulation in the access, and a few service providers have it running already.
In the long term, both 6RD and TSP will give way to reverse tunneling i.e. v4-in-v6, as this is the only way (after IPv4 depletion) for both protocols to co-exist on a host while having a mix of v4-only and dual-stack accessible services/website. Reverse tunneling's current protocols, DS-Lite and DSTM, are very similar to TSP's concept so the same clients & servers supporting TSP can be adapted to support DS-Lite.
Unfortunately, until IPv4 disappears from web content, hosts and servers these coexistence mechanisms will be needed.
Regards, -Ahmed
From: Kurt Smolderen Sent: Monday, February 28, 2011 11:13 AM To: address-policy-wg@ripe.net 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
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 To: address-policy-wg@ripe.net 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
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<mailto:K.Smolderen@edpnet.net> Sent: Monday, February 28, 2011 11:13 AM To: address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net> 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
Hi Kurt, In 6RD, part of the IPv6 address takes the IPv4 address of the CPE, so there is an IPv4 dependency but only in the access side. Note that TSP is also supported by CPEs and edge servers solutions. Regards, -Ahmed From: Kurt Smolderen Sent: Monday, February 28, 2011 4:54 PM To: Ahmed Abu-Abed ; address-policy-wg@ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD 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 To: address-policy-wg@ripe.net 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
On Mon, Feb 28, 2011 at 02:44:53PM +0200, Ahmed Abu-Abed wrote:
Note that the /64 limitation is specific to 6RD protocol as I explained in an earlier email.
I fail to find this email, could you provide archive pointers or explain again? I'm not aware of any instrinct /64 limitation of 6RD, and existing implementations prove the contrary. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
According to RFC 5969 for 6rd: " Embedding less than the full 32 bits of a CE IPv4 address is possible only when an aggregated block of IPv4 addresses is available for a given 6rd domain. This may not be practical with global IPv4 addresses, but is quite likely in a deployment where private addresses are being assigned to CEs. " So the /64 limitation for 6rd applies when an aggregated block of IPv4 addresses is not being used. Regards, -Ahmed From: Daniel Roesen Sent: Tuesday, March 01, 2011 1:15 AM To: address-policy-wg@ripe.net Subject: [address-policy-wg] Re: IPv6 allocations for 6RD On Mon, Feb 28, 2011 at 02:44:53PM +0200, Ahmed Abu-Abed wrote:
Note that the /64 limitation is specific to 6RD protocol as I explained in an earlier email.
I fail to find this email, could you provide archive pointers or explain again? I'm not aware of any instrinct /64 limitation of 6RD, and existing implementations prove the contrary. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Tue, Mar 01, 2011 at 10:24:46AM +0200, Ahmed Abu-Abed wrote:
According to RFC 5969 for 6rd:
" Embedding less than the full 32 bits of a CE IPv4 address is possible only when an aggregated block of IPv4 addresses is available for a given 6rd domain. This may not be practical with global IPv4 addresses, but is quite likely in a deployment where private addresses are being assigned to CEs. "
So the /64 limitation for 6rd applies when an aggregated block of IPv4 addresses is not being used.
I cannot read that in there. Above paragraphs talks about sub-32bit mapping of IPv4 endpoint addresses. This is orthogonal to what the prefix size for your customer delegation is. Example: your 6RD domain is a /27 IPv4 block. You can serve that with an IPv6 /51 block, giving each 6RD customer a /56. IPv4 /27 == 5 relevant bits (host addressing), 51+5=56. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hi, On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote:
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.
Without commenting on the general idea of allocating a larger chunk of addresses to ISPs, I want to make sure that the underlying facts are presented correctly. While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way - the current 6rd work in the IETF (draft-ietf-softwire-ipv6-6rd-10.txt) uses a more flexible approach: ---- quote ---- 6rd allows the SP to adjust the size of the 6rd prefix, how many bits used by the 6rd mechanism, and how many bits are left to be delegated to customer sites. ... For example, if the 6rd prefix is /32 and 24 bits of the CE IPv4 address is used (e.g all CE IPv4 addresses can be aggregated by a 10.0.0.0/8), then the size of the 6rd delegated prefix for each CE is automatically calculated to be /56 (32 + 24 = 56). ---- quote ---- so, depending on the size and fragmentation of the IPv4 address allocations an ISP might have available, he could run fully-functional 6rd with "/60 to end users" in a /36 IPv6 space (by only mapping 24 bits). So what I would like to see added to this discussion is: - what 6rd implementations are there "out in the market" today? (both provider and CPE side) - what approach do they take? "always use 32 bits for mapping" or the configurable approach from the i-d quoted above (IPv4MaskLen > 0)? Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Feb 28, 2011, at 3:20 PM, Gert Doering wrote:
Hi,
On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote:
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.
Without commenting on the general idea of allocating a larger chunk of addresses to ISPs, I want to make sure that the underlying facts are presented correctly.
While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way - the current 6rd work in the IETF (draft-ietf-softwire-ipv6-6rd-10.txt) uses a more flexible approach:
Yes! Except that is now published RFC 5969. RFC 5569 (five five six nine) describes the deployment at Free Telecom. RFC 5969 (five nine six nine) describes the IETF standards track protocol spec for 6rd. I really hope that most implementations are using RFC 5969 (certainly the commercial ones I know of are).
---- quote ---- 6rd allows the SP to adjust the size of the 6rd prefix, how many bits used by the 6rd mechanism, and how many bits are left to be delegated to customer sites. ... For example, if the 6rd prefix is /32 and 24 bits of the CE IPv4 address is used (e.g all CE IPv4 addresses can be aggregated by a 10.0.0.0/8), then the size of the 6rd delegated prefix for each CE is automatically calculated to be /56 (32 + 24 = 56). ---- quote ----
so, depending on the size and fragmentation of the IPv4 address allocations an ISP might have available, he could run fully-functional 6rd with "/60 to end users" in a /36 IPv6 space (by only mapping 24 bits).
So what I would like to see added to this discussion is:
- what 6rd implementations are there "out in the market" today? (both provider and CPE side)
For Cisco: Cisco has been shipping a BR (provider) side side since mid-2010. CE-side in IOS products since a few months after that. linksys gear has been part of many SP trials around the world since mid last year, and is expected to appear on retail shelves RSN.
- what approach do they take? "always use 32 bits for mapping" or the configurable approach from the i-d quoted above (IPv4MaskLen > 0)?
The majority of deployments I have seen use IPv4MaskLen == 0. There is no arguing that provisioning is simpler in this mode. . - Mark
Gert Doering -- APWG chair -- did you enable IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Mon, Feb 28, 2011 at 03:20:42PM +0100, Gert Doering wrote:
- what 6rd implementations are there "out in the market" today? (both provider and CPE side)
I know of (and can are not under NDA) _and_ got my hands on: BR: Cisco ASR1k CPE: AVM FritzBox
- what approach do they take? "always use 32 bits for mapping" or the configurable approach from the i-d quoted above (IPv4MaskLen > 0)?
Cisco IOS (on ASR1k): fully flexible configurable AVM: currently fixed /63 (as they may use routed mode between LAN and WiFi, thus two /64s needed) with full 32bit IPv4 mapping, in future flexible on v4-mapping width and delegated subnet size down to /63 or even /64. Ideally, IFF we would use 6RD, we'd like to have a single /24 block to support full 32bit IPv4 address mapping while providing a /56 to customers. Fiddling around with all your different IPv4 PA aggregates, splitting 6RD domains and trying to find halfway suitable space for those in your "normal" IPv6 allocation to support 6RD is.... well, a significant cost for operational point of view, making 6RD actually not that "rapid" and cheap to deploy. The present RIPE policies do add non-negliable indirect cost to deploy 6RD. At least if your plan is to go proper dual-stack "everywhere" over time and you want to use a nice-and-shiny addressing scheme for your allocation, not disturbed by large 6RD blocks. See other folks' recent comments here. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Le 28 févr. 2011 à 15:20, Gert Doering a écrit :
Hi,
On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote:
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.
Without commenting on the general idea of allocating a larger chunk of addresses to ISPs, I want to make sure that the underlying facts are presented correctly.
While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way
It doesn't have to, right. But, if being native permits to deploy good IPv6 service to the masses before other means to do it are available, being naive is better than being overly purist. For ISPs that have been assigned several IPv4 prefixes (as many have been), the "naive" approach remains the simplest one to operate. Regards, RD
If simplicity in IPv6 transition means initially offering IPv6-over-IPv4 to subscribers while meeting 2 fundamental requirements, namely end-user prefix delegation and commercial hardware CPE support, then there are 3 protocols that can be used depending on the service provider requirements: 6rd, TSP and L2TP. If implementing 6rd, service providers may need an allocation larger than /32 as the 6rd protocol embeds the users IPv4 address, or part there of, in their IPv6 address. Regards, -Ahmed From: Rémi Després Sent: Thursday, March 10, 2011 9:10 PM To: Gert Doering Cc: Kurt Smolderen ; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD Le 28 févr. 2011 à 15:20, Gert Doering a écrit :
Hi,
On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote:
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.
Without commenting on the general idea of allocating a larger chunk of addresses to ISPs, I want to make sure that the underlying facts are presented correctly.
While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way
It doesn't have to, right. But, if being native permits to deploy good IPv6 service to the masses before other means to do it are available, being naive is better than being overly purist. For ISPs that have been assigned several IPv4 prefixes (as many have been), the "naive" approach remains the simplest one to operate. Regards, RD
Le 13 mars 2011 à 07:26, Ahmed Abu-Abed a écrit :
If simplicity in IPv6 transition means initially offering IPv6-over-IPv4 to subscribers while meeting 2 fundamental requirements, namely end-user prefix delegation and commercial hardware CPE support, then there are 3 protocols that can be used depending on the service provider requirements: 6rd, TSP and L2TP.
If implementing 6rd, service providers may need an allocation larger than /32 as the 6rd protocol embeds the users IPv4 address, or part there of, in their IPv6 address.
Agreed. Assigning prefixes shorter than /32 to ISP's that accelerate IPv6 deployment with 6rd is IMHO the right choice to promote IPv6 with native addresses. Regards, RD
Regards, -Ahmed
From: Rémi Després Sent: Thursday, March 10, 2011 9:10 PM To: Gert Doering Cc: Kurt Smolderen ; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD
Le 28 févr. 2011 à 15:20, Gert Doering a écrit :
Hi,
On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote:
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.
Without commenting on the general idea of allocating a larger chunk of addresses to ISPs, I want to make sure that the underlying facts are presented correctly.
While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way
It doesn't have to, right. But, if being native permits to deploy good IPv6 service to the masses before other means to do it are available, being naive is better than being overly purist. For ISPs that have been assigned several IPv4 prefixes (as many have been), the "naive" approach remains the simplest one to operate.
Regards, RD
This implies that if assigning prefixes shorter than /32 is not possible, then other transition protocols such as TSP or L2TP can be used to enable rapid IPv6 transition. TSP in particular is quite easy to deploy over any type IPv4 access network and with existing CPEs as it can work behind the ISP access modem. Regards, -Ahmed From: Rémi Després Sent: Sunday, March 13, 2011 11:22 AM To: Ahmed Abu-Abed Cc: RIPE Address Policy Subject: Re: [address-policy-wg] IPv6 allocations for 6RD Le 13 mars 2011 à 07:26, Ahmed Abu-Abed a écrit :
If simplicity in IPv6 transition means initially offering IPv6-over-IPv4 to subscribers while meeting 2 fundamental requirements, namely end-user prefix delegation and commercial hardware CPE support, then there are 3 protocols that can be used depending on the service provider requirements: 6rd, TSP and L2TP.
If implementing 6rd, service providers may need an allocation larger than /32 as the 6rd protocol embeds the users IPv4 address, or part there of, in their IPv6 address.
Agreed. Assigning prefixes shorter than /32 to ISP's that accelerate IPv6 deployment with 6rd is IMHO the right choice to promote IPv6 with native addresses. Regards, RD
Regards, -Ahmed
From: Rémi Després Sent: Thursday, March 10, 2011 9:10 PM To: Gert Doering Cc: Kurt Smolderen ; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD
Le 28 févr. 2011 à 15:20, Gert Doering a écrit :
Hi,
On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote:
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.
Without commenting on the general idea of allocating a larger chunk of addresses to ISPs, I want to make sure that the underlying facts are presented correctly.
While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way
It doesn't have to, right. But, if being native permits to deploy good IPv6 service to the masses before other means to do it are available, being naive is better than being overly purist. For ISPs that have been assigned several IPv4 prefixes (as many have been), the "naive" approach remains the simplest one to operate.
Regards, RD
participants (7)
-
Ahmed Abu-Abed -
Daniel Roesen -
Gert Doering -
Kurt Smolderen -
Mark Townsley -
Randy Bush -
Rémi Després