Sent from my iPad
On Jan 17, 2013, at 6:58 PM, Joe Maimon <jmai...@ttec.com> wrote: > > > Owen DeLong wrote: > >> And this is where you run off the rails… You are assuming that NAT today >> and CGN provide similar functionality from an end-user perspective. > > To the extent that CGN functions like the clueless linksys daisy-chain, then > yes it does. Right, but it that extent is very limited. >> >> The reality is that they do not. CGN is a substantially more degraded >> form of internet access than current traditional per-site NAT. >> >> 1. The end-site does not control the NAT box. > > The vast majority of end site today either do not control the NAT box or do > not know how to control the NAT box. > Bzzt... They may not actively control it through an administrative interface, but, there is not some other administrator actively disabling functionality they care about. >> 2. UPnP and NAT-PMP do NOT work through CGN. > > And without this wondrous technology, nothing works behind a NAT! Whatever > did we do before the invention and mass adoption of UPnP and NAT-PMP! Many things that users depend on and like do not work without it. Those things did not work/did not exist much before UPnP/NAT-PMP. That is the reason UPnP and NAT-PMP were developed and gained such wide acceptance so quickly. Prior to that, some popular applications also received customized ALGs implemented in most NAT boxes. >> 3. There is no other provision in most CGNs to allow for inbound >> connection trickery that allows many of today's applications to >> function in spite of NAT. > > Clearly we have run out of trickery as multiple layers of NAT stumps even the > finest of our tricksters. Yes, we can dedicate thousands more developer hours to making yet more extensions to code to work around yet more NAT and maybe make it sort of kind of work almost as poorly as it does now. Or we could pour a fraction of those developer hours into implementing IPv6 in those same applications and have the problem solved in perpetuity. > We will have to wait and see on this one. There is a complex interaction > between protocol development, application deployment, cpe technology and user > behavior all influenced by the NAT reality we are all witness to. Yep. The trick is figuring out how to educate developers so that we can get OFF the damn NAT merry-go-round. NAT at this point has become the internet equivalent of charging $2 more than you pay on your credit card each month and wondering why the bill never shrinks. > Will this interaction adopt and adapt CGN? Clearly your opinion is not, but > its only an opinion. Actually, I'm more afraid that it will for some time to come. Results of continuing to do so: 1. Applications cost more. 2. Applications become progressively even more fragile and more poorly implemented that the current state of affairs. 3. Security goes even more out the window than it already has because there will be even less ability to identify the source of malicious conduct than there is today. 4. Routers cost more. 5. Router software continues to become more complex and more fragile and even more poorly implemented than the current state of the average home gateway while not actually adding any new functionality, just continuing to escalate the arms race to stay where we are in the face of an ever worsening NAT environment. 6. Performance continues to degrade on the alter of ever more layers of translation, obfuscation, hackery, workarounds, etc. My hope is that we will realize at some point that this is a badly loosing proposition, but, my fear is that we will actually find ways to make it work and worse yet, dedicate resources to doing so. IMHO, having it fail miserably is the best case scenario. The alternatives are far worse. >>> Wireless has - remind me - how many /8's compared to, say, Google? >> >> Are you sure that 75% of VZW's IP addresses are assigned to end-customer >> devices? I am not. > > No, actually, I believe what he said is that OF the Addresses ASSIGNED to > devices, 75% are end-customers. Even that is a statistic of which I am unconvinced without better evidence. > Far more are likely not in use by any specific device at any given point in > time. Sure, but let's go with the modified statement you give above. That assumes that VZW's entire network infrastructure, including billing systems, backhaul, provisioning, helpdesk, call centers, offices, servers, etc. all adds up to less than 1/4 of the total devices connected to their network. I highly doubt it. > And what else exactly would VZW be doing with those addresses? Running more > servers and infrastructure then wireless clients to use them? I'd believe 50% or maybe even 65%, but 75% stretches credibility. See above for a partial list of the various things I expect they are doing with those addresses. >> First, it's more like 1/100 customers that are not already behind NAT >> of some form, so your 37 years drops to 0.37 years (a little more than >> 4 months). > > Rather disingenuous of you. We are not addressing "some form" of nat. We are > addressing the specific form of CGN. Of which far fewer then 1/100 customers > are behind. Then it's equally disingenuous to use VZW end-user device counts as well. > How about much simpler math. Assume 75% IP in any provider organization are > for subscribers. Assume an average 5-10 subscribers per CGN IP. I don't believe the first assumption and I think that more than about 3 is rather optimistic for the second one, actually. Especially in the face of dedicated port range CGN proposed by most of the ISPs I know have real plans to implement CGN rather than just a "yeah, we'll do that when we have to" approach. > Clearly, that organization's subscriber growth will be limited by CGN > technology, not by address scarcity. Why? Does it not scale linearly? If not, why not? >> This seems very disruptive and rather heavy on the overhead for a 4-month >> stop-gap. > > > > Owen > > > > > > Think locally for a bit. Addresses are not instantaneously fungible across > the internet. Any provider who can pull this off will have far more then a > 4-month stop-gap. They may even have enough to peddle on the market. I think that's very optimistic. I'm not sure why you say they are not instantaneously fungible. It takes me only a few seconds to move an address around between locations I control and only a little longer if I want to move it around with someone else who is interested in cooperating in that move. Owen
