Ah, thanks. I was considering this from a CE only perspective.
-andrew-------- Original message -------- From: Mel Beckman <m...@beckman.org> Date: 07/06/2015 10:49 AM (GMT-05:00) To: andrew <and...@ethernaut.io> Cc: Lee Howard <l...@asgard.org>, Josh Moore <jmo...@atcnetworks.net>, nanog@nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion MPLS requires an IPv4 core. You can't run an IPv6-only infrastructure because neither CSCO or JNPR have implemented LDP to distribute labels for IPV6 prefixes. -mel via cell On Jul 6, 2015, at 7:15 AM, andrew <and...@ethernaut.io> wrote: Pardon my ignorance - what do you see missing in MPLS in regards to support for IP6? -------- Original message -------- From: Mel Beckman <m...@beckman.org> Date: 07/06/2015 9:44 AM (GMT-05:00) To: Lee Howard <l...@asgard.org> Cc: Josh Moore <jmo...@atcnetworks.net>, nanog@nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion And let's all complain to the MPLS working group to get IPv6 support finished up! -mel beckman > On Jul 6, 2015, at 6:27 AM, Lee Howard <l...@asgard.org> wrote: > > Some thoughts. . . > > ³Native dual-stack² is ³native IPv4 and native IPv6.² > > ³Dual-stack² might be native, or might by ³native IPv6 plus IPv4 address > sharing.² > > Your IPv4 address sharing options are CGN, DS-Lite, and MAP. There are > operational deployments of all three, in the order given. You need them > close enough to your customers that traffic will return over the same > path. You can¹t share state among a cluster of boxes, but that¹s not the > end of the world; a device failure sometimes causes loss of state. MAP is > the hot new thing all the cool kids are doing. > > Look to your router and load balancer vendors for devices that do these. > CGN is the only one that doesn¹t require updates to the home gateway. The > more IPv6 your customers use, the smaller your CGN/AFTR/MAP can be. > > Think about how you¹ll position it to customers. It¹s difficult to change > a customer¹s service mid-contract. At some point, a customer is no longer > profitable: if NAT costs and service calls add up, you may be better off > buying addresses or losing the customer. You may need to buy some IPv4 > addresses to give you time; contact a broker. > > You may be surprised how hard it is to root IPv4 out of the system. Don¹t > buy anything you can¹t manage over IPv6, including servers and > applications. Sorry, vendor, I can¹t buy your cluster, I don¹t have the > IPv4 address space to provision it. > > Lee > > On 7/4/15, 8:09 AM, "NANOG on behalf of Josh Moore" > <nanog-boun...@nanog.org on behalf of jmo...@atcnetworks.net> wrote: > >> Traditional dual stack deployments implement both IPv4 and IPv6 to the >> CPE. >> Consider the following: >> >> An ISP is at 90% IPv4 utilization and would like to deploy dual stack >> with the purpose of allowing their subscriber base to continue to grow >> regardless of the depletion of the IPv4 space. Current dual stack best >> practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If >> this is the case, and BOTH are still required, then how does IPv6 help >> with the v4 address depletion crisis? Many sites and services would still >> need legacy IPv4 compatibility. Sure, CGN technology may be a solution >> but what about applications that need direct IPv4 connectivity without >> NAT? It seems that there should be a mechanism to enable on-demand and >> efficient IPv4 address consumption ONLY when needed. My question is this: >> What, if any, solutions like this exist? If no solution exists then what >> is the next best thing? What would the overall IPv6 migration strategy >> and goal be? >> >> Sorry for the length of this email but these are legitimate concerns and >> while I understand the need for IPv6 and the importance of getting there; >> I don't understand exactly HOW that can be done considering the immediate >> issue: IPv4 depletion. >> >> >> Thanks >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 > >
