Re: Verizon DSL moving to CGN
On Sun, 7 Apr 2013, Owen DeLong wrote: I don't disagree. You are actually making the exact point I was attempting to make. The need for CGN is not divorced from the failure to deploy IPv6, it is caused by it. Absolutely. That doesn't mean that any individual ISP right now can choose to *not* implement CGN and deploy IPv6. That won't solve IPv4 address depletion *for that ISP*. This is an industry-wide failure that no individual part of the industry can work around. For most ISPs, deploying some kind of CGN is the only rational decision at this time. We can discuss what could have should have happened earlier, but now we're here. Yes, ISPs should deploy IPv6. Everybody should deploy IPv6. But I still believe that CGN is mostly orthogonal to IPv6 deployment. Saying ISPs today are wrong to deploy CGN and that they should deploy IPv6 (the word instead is usually not there, but it still seems to be implied), I just don't understand that argument. Is it just that the ISP in question hasn't announced their IPv6 plans in the same announcement that is the problem? So that people believe CGN is part of a future-proof strategy? So if the ISP says we're going to deploy CGN for select customers during 2H-2013 due to IPv4 run-out, and at the same time we're planning to start rolling out IPv6 for customers who have upgradable equipment, does that help? If the ISP has been around for a while, it's still a huge part of the customer base that won't be upgradable, and those customers will be stuck behind NAT444 until they do something. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Verizon DSL moving to CGN
* Owen DeLong The need for CGN is not divorced from the failure to deploy IPv6, it is caused by it. In a historical context, this is true enough. If we had accomplished ubiquitous IPv6 deployment ten years ago, there would be no IPv4 depletion, and there would be no CGN. However, that ship has sailed long ago. You're using present tense where you should have used past. I was responding to Mikael's claim that pushing content providers to deploy IPv6 was orthogonal to the need for CGN. If we put down the history books and focus on today's operational realities, it *is* orthogonal. If you're an ISP fresh out of IPv4 addresses today, pushing content providers to deploy IPv6 is simply not a realistic strategy to deal with it. CGN is. Clearly your statement here indicates that you see my point that it is NOT orthogonal, but, in fact the failure of content providers to deploy IPv6 _IS_ the driving cause for CGN. I'm not sure why you are singling out content providers, BTW. There are no shortage of other things out there that have an absolute hard requirement on IPv4 to function properly. Gaming consoles, Android phones and tables, iOS phones and tablets[1], home gateways, software and apps, embedded devices, ... - the list goes on and on. If the only missing piece of the puzzle was the lack of IPv6 support at the content providers' side, IPv6+NAT64 would constitute a perfectly viable residential/cellular internet service. As far as I know, however, not a single provider is seriously considering this strategy going forward. That's telling. Tore [1] From what I hear, anyway. They used to work fine on IPv6-only wireless networks, I've seen it myself, but I've been told that it's taken a turn for the worse over the course of the last year.
Re: Open Resolver Dataset Update
On 7/04/2013 19:46, Jared Mauch wrote: I've continued to update my dataset originally posted about two weeks ago. Please take a moment and review your CIDRs which may be running an open resolver. I've exposed one additional bit in the user-interface that may be helpful. Some DNS servers will respond with RCODE=0 (OK) but not provide recursion. nearly 90% of the servers in the database provide recursion. What is the rationale behind listing servers not providing recursion on a list of open resolvers? As far as I know, responding either NOERROR or REFUSED produces packets of the same size. Tom
Re: Open Resolver Dataset Update
In message 51626cf9.1040...@phyxia.net, Tom Laermans writes: On 7/04/2013 19:46, Jared Mauch wrote: I've continued to update my dataset originally posted about two weeks ago. Please take a moment and review your CIDRs which may be running an open resolver. I've exposed one additional bit in the user-interface that may be helpful. Some DNS servers wil l respond with RCODE=0 (OK) but not provide recursion. nearly 90% of the servers in the database provide recursion. What is the rationale behind listing servers not providing recursion on a list of open resolvers? As far as I know, responding either NOERROR or REFUSED produces packets of the same size. Tom NOERROR can be a referral. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Verizon DSL moving to CGN
On Apr 7, 2013, at 23:27 , Tore Anderson t...@fud.no wrote: * Owen DeLong The need for CGN is not divorced from the failure to deploy IPv6, it is caused by it. In a historical context, this is true enough. If we had accomplished ubiquitous IPv6 deployment ten years ago, there would be no IPv4 depletion, and there would be no CGN. However, that ship has sailed long ago. You're using present tense where you should have used past. Respectfully, I disagree. If the major content providers were to deploy IPv6 within the next 6 months (pretty achievable even now), then the need for CGN would at least be very much reduced, if not virtually eliminated. I was responding to Mikael's claim that pushing content providers to deploy IPv6 was orthogonal to the need for CGN. If we put down the history books and focus on today's operational realities, it *is* orthogonal. If you're an ISP fresh out of IPv4 addresses today, pushing content providers to deploy IPv6 is simply not a realistic strategy to deal with it. CGN is. This does not represent a reason to stop pushing content providers. While CGN may be a necessary stop-gap measure today for some, there are many more who aren't facing that decision for a few months. Even for those that do have to deploy it, the reality is that CGN is fragile, unwieldy, expensive, and high-maintenance. Further, it provides a lousy customer experience. The less you have to depend on CGN as an ISP, the better your life will be. As such, it is even more vital today than it was in history to keep the pressure for IPv6 content strong. Clearly your statement here indicates that you see my point that it is NOT orthogonal, but, in fact the failure of content providers to deploy IPv6 _IS_ the driving cause for CGN. I'm not sure why you are singling out content providers, BTW. There are no shortage of other things out there that have an absolute hard requirement on IPv4 to function properly. Gaming consoles, Android phones and tables, iOS phones and tablets[1], home gateways, software and apps, embedded devices, ... - the list goes on and on. All of those things are actually driven primarily by content. iOS phones and tables are perfectly capable of IPv6 where IPv6 is available over WiFi. iPhone 5 can do IPv6 over the carrier network. I know, my iPhone 5 works great with IPv6 on its network. Home gateways are going to need to be replaced. There are plenty of them that do support IPv6. Gaming consoles are entirely under the control of content providers. Most of the embedded devices are either going to need to be replaced over time, upgraded, or we're going to need some form of set-top box to deal with them in the future. Bottom line, content providers are the low-hanging fruit in terms of the easiest and fastest way to have the biggest impact in reducing the need for and load on CGN deployments. If the only missing piece of the puzzle was the lack of IPv6 support at the content providers' side, IPv6+NAT64 would constitute a perfectly viable residential/cellular internet service. As far as I know, however, not a single provider is seriously considering this strategy going forward. That's telling. It's not the only piece, just the easiest one to solve immediately with the biggest payoff. Tore [1] From what I hear, anyway. They used to work fine on IPv6-only wireless networks, I've seen it myself, but I've been told that it's taken a turn for the worse over the course of the last year. Actually it took a brief turn for the worse due to a bug which has now been (partially) resolved. Apparently the phones used to prefer IPv6 over carrier if they were on a wireless v4-only network which ran up some (startling) data charges for some users. Now they've made it so that if you have a wifi connection, you simply won't use the cellular network no matter what. This unfortunately means that you cannot surf an IPv6-only site while you are connected to an IPv4-only wifi network even if you have dual-stack carrier connectivity, but I think that's a reasonable tradeoff for now. Prior to this latest software/carrier settings update, they had simply turned off IPv6 on the carrier side, but the wifi side has always worked since one of the later versions of IOS4 or one of the earlier versions of IOS5, I forget which. Owen
Re: Verizon DSL moving to CGN
On Mon Apr 08, 2013 at 01:41:34AM -0700, Owen DeLong wrote: Respectfully, I disagree. If the major content providers were to deploy IPv6 within the next 6 months (pretty achievable even now), then the need for CGN would at least be very much reduced, if not virtually eliminated. Surely the case is that you've still got the same number of users who need an IPv4 address to be able to access legacy IPv4 sites on the Internet - until 100% of content is accessible via IPv6. What it does, however, change is the amount of traffic which would need to flow through a CGN box. Unfortunately, CGN is here until either everything is available over IPv6, or a better version of NAT64 which doesn't depend on DNS rewriting is designed and deployed. Simon
Re: Verizon DSL moving to CGN
On 4/8/13 9:41 AM, Owen DeLong wrote: On Apr 7, 2013, at 23:27 , Tore Anderson t...@fud.no wrote: * Owen DeLong The need for CGN is not divorced from the failure to deploy IPv6, it is caused by it. In a historical context, this is true enough. If we had accomplished ubiquitous IPv6 deployment ten years ago, there would be no IPv4 depletion, and there would be no CGN. However, that ship has sailed long ago. You're using present tense where you should have used past. Respectfully, I disagree. If the major content providers were to deploy IPv6 within the next 6 months (pretty achievable even now), then the need for CGN would at least be very much reduced, if not virtually eliminated. I though that they have done it last year around June 8th. ;-) In fact, the need for CGN has been reduced if you count that 30-40% of your traffic would go to those places. Although CGN is going to be a necessary evil, deploying CGN without IPv6 would be a mistake IMHO. /as
Re: Verizon DSL moving to CGN
On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote: Thankfully, MAP is not CGN. Correctly stated, unlike DS-Lite, MAP doesn't require any CGN that causes the SP network to put up with the NAT state. This means that all the subsequent issues of CGN/DS-Lite no longer apply. For me as an operator, MAP is most likely going to be implemented in a CGN-like box. Yes, it's stateless. Doesn't matter, I still need to flow traffic through a dedicated box because MAP won't be implemented in my regular routers (if you know otherwise, please speak up). MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled access. MAP makes much more sense in any SP network having its internet customers do IPv4 address sharing and embrace IPv6. It's still NAT. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Verizon DSL moving to CGN
* Mikael Abrahamsson On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote: MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled access. MAP makes much more sense in any SP network having its internet customers do IPv4 address sharing and embrace IPv6. It's still NAT. AIUI, the standards-track flavour of MAP, MAP-E, is *not* NAT - it is tunneling, pure encap/decap plus a clever way to calculate the outer IPv6 src/dst addresses from the inner IPv4 addresses and ports. The inner IPv4 packets are not modified by the centralised MAP tunneling routers, so there is no Network Address Translation being performed. The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44 component though, so there is some NAT involved in the overall solution, but it's pretty much the same as what we have in today's CPEs/HGWs. The only significant difference is that a MAP CPE must be prepared to not being able to use all the 65536 source ports. Tore
Re: Verizon DSL moving to CGN
* Owen DeLong Respectfully, I disagree. If the major content providers were to deploy IPv6 within the next 6 months (pretty achievable even now), then the need for CGN would at least be very much reduced, if not virtually eliminated. I agree with very much reduced. However, and IMHO, virtually eliminated is completely unrealistic. The less you have to depend on CGN as an ISP, the better your life will be. As such, it is even more vital today than it was in history to keep the pressure for IPv6 content strong. [...] Bottom line, content providers are the low-hanging fruit in terms of the easiest and fastest way to have the biggest impact in reducing the need for and load on CGN deployments. If the only missing piece of the puzzle was the lack of IPv6 support at the content providers' side, IPv6+NAT64 would constitute a perfectly viable residential/cellular internet service. As far as I know, however, not a single provider is seriously considering this strategy going forward. That's telling. It's not the only piece, just the easiest one to solve immediately with the biggest payoff. I agree fully that the continued deployment of IPv6 on the content side and all other places is a benefit to any ISP that is providing IPv6 to their subscribers alongside CGN. The payoff is reduced customer unhappiness due to the effects of CGN, and reducing the amount of investment in CGN necessary. But the payoff is not going to be avoiding to have to implement CGN (or similar IPv4 life-support mechanisms, including MAP) in the first place, no matter how hard one pushes for IPv6. In order for that that to be the case, *all* the missing pieces must fall in place, not only the biggest/easiest ones - and there's simply too many small and tricky ones left, and too little time. I cannot see any realistic outcome of the ordeal we're currently in that does not include CGN or similar stuff to handle the long tail of IPv4-only stuff. It's simply too late for IPv6 to prevent CGN. I'd be absolutely delighted, though, if I'm wrong and you're able to say to me a few years from now «I told you so»! :-) Tore
Re: Verizon DSL moving to CGN
On Mon, 8 Apr 2013, Tore Anderson wrote: * Mikael Abrahamsson On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote: MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled access. MAP makes much more sense in any SP network having its internet customers do IPv4 address sharing and embrace IPv6. It's still NAT. AIUI, the standards-track flavour of MAP, MAP-E, is *not* NAT - it is tunneling, pure encap/decap plus a clever way to calculate the outer IPv6 src/dst addresses from the inner IPv4 addresses and ports. The inner IPv4 packets are not modified by the centralised MAP tunneling routers, so there is no Network Address Translation being performed. This is all splitting hairs. Yes, the outside port addresses do not change but however the src/dst addresses change (=translated), right? Does anyone see MAP-E being implemented on regular linecards or is it going to be implemented on processor based dedicated hardware? At least initially, I would just assume it's going to be some kind of CGN blade. The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44 component though, so there is some NAT involved in the overall solution, but it's pretty much the same as what we have in today's CPEs/HGWs. The only significant difference is that a MAP CPE must be prepared to not being able to use all the 65536 source ports. Yes, MAP-E needs CPE support, thus hard to deploy short term. Long term, yes, really nice. Perfect for long tail IPv4 reachability over IPv6 access networks. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Open Resolver Dataset Update
The referral, including a referral to root can be quite large. Even larger than answering a normal query. I have broken the data out for the purpose of letting people identify the IPs that provide that. Jared Mauch On Apr 8, 2013, at 3:08 AM, Tom Laermans tom.laerm...@phyxia.net wrote: As far as I know, responding either NOERROR or REFUSED produces packets of the same size.
Re: Verizon DSL moving to CGN
* Mikael Abrahamsson On Mon, 8 Apr 2013, Tore Anderson wrote: AIUI, the standards-track flavour of MAP, MAP-E, is *not* NAT - it is tunneling, pure encap/decap plus a clever way to calculate the outer IPv6 src/dst addresses from the inner IPv4 addresses and ports. The inner IPv4 packets are not modified by the centralised MAP tunneling routers, so there is no Network Address Translation being performed. This is all splitting hairs. Yes, the outside port addresses do not change but however the src/dst addresses change (=translated), right? There is no outside port addresses. The Next Header field in the outside IPv6 header is set to 4 (i.e., what follows next is an IPv4 header). This inner IPv4 header (and the payload following it) is the original one and completely unmodified and not translated/rewritten in any way by the ISP's MAP gateway. AIUI, anyway. So unless you mean that the src/dst address change or are translated due to the addresses in the outer IPv6 header are not the same as in the inner IPv4 header, there is simply is no translation happening here. If this is to be called translation, then any tunneling mechanism that works by stacking layer-3 headers, including GRE, IPIP, ESP, and proto-41, must be also called translation. Does anyone see MAP-E being implemented on regular linecards or is it going to be implemented on processor based dedicated hardware? At least initially, I would just assume it's going to be some kind of CGN blade. No idea, sorry. Tore
Re: Verizon DSL moving to CGN
* Tore Anderson Does anyone see MAP-E being implemented on regular linecards or is it going to be implemented on processor based dedicated hardware? At least initially, I would just assume it's going to be some kind of CGN blade. No idea, sorry. https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf slide 15: «Processed inline with normal IP traffic (at least on Cisco’s ASR9K)» Tore
Re: Verizon DSL moving to CGN
On Mon, 8 Apr 2013, Tore Anderson wrote: If this is to be called translation, then any tunneling mechanism that works by stacking layer-3 headers, including GRE, IPIP, ESP, and proto-41, must be also called translation. Oki, my bad. I read https://ripe65.ripe.net/presentations/91-townsley-map-ripe65-ams-sept-24-2012.pdf and obviously didn't understand. I thought only the payload was encapsulated, not the complete IPv4 packet. It said replace IPv4 header with IPv6 header and I missed that this was for MAP-T, not MAP-E). Thanks for explaining. I understand why MAP-E is not translation now. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Verizon DSL moving to CGN
* Tore Anderson The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44 component though, so there is some NAT involved in the overall solution, but it's pretty much the same as what we have in today's CPEs/HGWs. The only significant difference is that a MAP CPE must be prepared to not being able to use all the 65536 source ports. BTW. It is AIUI quite possible with MAP to provision a whole IPv4 address or even a prefix to the subscriber, thus also taking away the need for [srcport-restricted] NAPT44 in the CPE. I find that the easiest way to visualise MAP is to take the 16 bits of TCP/UDP port space, and bolt it onto the end of the 32 bits of the IPv4 address space, for a total of 48 routable bits. So while the primary use case for MAP is to provision less than 32 bits to the individual customers (say a /34 - 4 subscribers per IPv4 address w/16k ports each), you can also give out a whole /32 or a /24 or whatever - perhaps only to the customers that are willing to pay for the privilege. I haven't tested, but I believe that if you were to hook up a standard Linux box to a ISP that provides /32 or shorter over MAP, you don't really need any special MAP support in the IP stack to make it go - you'd have to calculate the addresses to be used yourself, but once you've got them, you could just configure everything using standard ip tunnel/address commands. It's quite neat, I think. :-) Tore
Re: Verizon DSL moving to CGN
On 4/8/2013 7:20 AM, Tore Anderson wrote: BTW. It is AIUI quite possible with MAP to provision a whole IPv4 address or even a prefix to the subscriber, thus also taking away the need for [srcport-restricted] NAPT44 in the CPE. The problem is NAPT44 in the CPE isn't enough. We are reaching the point that 1 IPv4 Address per customer won't accommodate user bases. The larger issue I think with MAP is CPE support requirements. There are ISP layouts that use bridging instead of CPE routers (which was a long term design to support IPv6 without CPE replacements years later). CGN will handle the IPv4 issues in this setup just fine. Then there are those who have already deployed IPv6 capable CPEs with PPP or DHCP in a router configuration which does not have MAP support. Given the variety of CPE vendors that end up getting deployed over a longer period of time, it is easier and more cost effective to deploy CGN than try and replace all the CPEs. Given US$35/CPE, cost for replacements (not including deployment costs) for 20k users is US$700k. CGN gear suddenly doesn't seem so costly. The only way I see it justifiable is if you haven't had IPv6 deployment in mind yet and you are having to replace every CPE for IPv6 support anyways, you might go with a MAPS/IPv6 aware CPE which the customer pays for if they wish IPv6 connectivity(or during whatever slow trickle replacement methods you utilize). While waiting for the slow rollout, CGN would be an interim cost that would be acceptable. I'm not sure there is a reason for MAPS if you've already deployed CGN, though. I am sure Verizon did a lot of cost analysis. Jack
Re: Verizon DSL moving to CGN
I understand why MAP-E is not translation now. so far, the sexiest implementation of statless a+p to date. randy
Re: Verizon DSL moving to CGN
In a message written on Mon, Apr 08, 2013 at 01:41:34AM -0700, Owen DeLong wrote: Respectfully, I disagree. If the major content providers were to deploy IPv6 within the next 6 months (pretty achievable even now), then the need for CGN would at least be very much reduced, if not virtually eliminated. I'm going to disagree, because the tail here I think is quite long. Owen is spot on when looking at the percentage of bits moved across the network. I suspect if the top 20 CDN's were to IPv6 enable _everything_ that 50-90% of the bits in most networks would be moved over native IPv6, depending on the exact mix of traffic in the network. However, CDN's are a _very_ small part of the address space. I'd be surprised if the top 20 CDN's had 0.01% of all IPv4 space. That leaves a lot of hosts that need to be upgraded. There's a lot of people who buy a $9.95/month VPS to host their personal blog read by 20 people who don't know anything about IPv4 or IPv6 but want to be able to reach their site. The traffic level may be non-interesting, but they will be quite unhappy without a CGN solution. Moving the CDN's to IPv6 native has the potential to save the access providers a TON of money on CGN hardware, due to the bandwidth involved. However those access providers still have to do CGN, otherwise their NOC's will be innondated with complaints about the inability to reach a bunch of small sites for a long period of time. If I were deploying CGN, I would be exerting any leverage I had on CDN's to go native IPv6. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp2htLLgGzH1.pgp Description: PGP signature
Re: Verizon DSL moving to CGN
On 4/8/13 7:23 AM, Jack Bates wrote: On 4/8/2013 7:20 AM, Tore Anderson wrote: BTW. It is AIUI quite possible with MAP to provision a whole IPv4 address or even a prefix to the subscriber, thus also taking away the need for [srcport-restricted] NAPT44 in the CPE. The problem is NAPT44 in the CPE isn't enough. We are reaching the point that 1 IPv4 Address per customer won't accommodate user bases. That happened a long time ago. I realize the people like to think of wireless providers as different, they really aren't. A big chuck of our mobile gaming customers come to us via carrier operated nat translators. Some of them now come to us via ipv6, most do not. The larger issue I think with MAP is CPE support requirements. There are ISP layouts that use bridging instead of CPE routers (which was a long term design to support IPv6 without CPE replacements years later). CGN will handle the IPv4 issues in this setup just fine. Then there are those who have already deployed IPv6 capable CPEs with PPP or DHCP in a router configuration which does not have MAP support. Given the variety of CPE vendors that end up getting deployed over a longer period of time, it is easier and more cost effective to deploy CGN than try and replace all the CPEs. Given US$35/CPE, cost for replacements (not including deployment costs) for 20k users is US$700k. CGN gear suddenly doesn't seem so costly. The only way I see it justifiable is if you haven't had IPv6 deployment in mind yet and you are having to replace every CPE for IPv6 support anyways, you might go with a MAPS/IPv6 aware CPE which the customer pays for if they wish IPv6 connectivity(or during whatever slow trickle replacement methods you utilize). While waiting for the slow rollout, CGN would be an interim cost that would be acceptable. I'm not sure there is a reason for MAPS if you've already deployed CGN, though. I am sure Verizon did a lot of cost analysis. Jack
Re: Verizon DSL moving to CGN
On 4/8/2013 9:58 AM, joel jaeggli wrote: That happened a long time ago. I realize the people like to think of wireless providers as different, they really aren't. A big chuck of our mobile gaming customers come to us via carrier operated nat translators. Some of them now come to us via ipv6, most do not. Yeah, forgive me. I have a tendency to forget the mobile carriers, probably because some of them started with CGN. One of my customers just started a new cell network. He's burning through /20's like they are nothing in a short time frame (and it's a small geographic area). They're deploying CGN so we don't run out of addresses and can recover what we've already burned through. IPv6 for their cellular didn't seem high priority either. Jack
Re: Verizon DSL moving to CGN
Indeed MAP-E requires CPE replacement/upgrade cost. But I would like to share JANOG Softwire WG Activity. http://conference.apnic.net/__data/assets/pdf_file/0005/58856/apnic35-janog-softwire_1361559276.pdf MAP-E already supported by 6 vendors,7 implementations. It includes 2 open source(OpenWRT and ASAMAP) and 2 kernel(Linux 2.6.18 and NetBSD 4.0.1). Regards, Shishio (2013/04/08 23:23), Jack Bates wrote: On 4/8/2013 7:20 AM, Tore Anderson wrote: BTW. It is AIUI quite possible with MAP to provision a whole IPv4 address or even a prefix to the subscriber, thus also taking away the need for [srcport-restricted] NAPT44 in the CPE. The problem is NAPT44 in the CPE isn't enough. We are reaching the point that 1 IPv4 Address per customer won't accommodate user bases. The larger issue I think with MAP is CPE support requirements. There are ISP layouts that use bridging instead of CPE routers (which was a long term design to support IPv6 without CPE replacements years later). CGN will handle the IPv4 issues in this setup just fine. Then there are those who have already deployed IPv6 capable CPEs with PPP or DHCP in a router configuration which does not have MAP support. Given the variety of CPE vendors that end up getting deployed over a longer period of time, it is easier and more cost effective to deploy CGN than try and replace all the CPEs. Given US$35/CPE, cost for replacements (not including deployment costs) for 20k users is US$700k. CGN gear suddenly doesn't seem so costly. The only way I see it justifiable is if you haven't had IPv6 deployment in mind yet and you are having to replace every CPE for IPv6 support anyways, you might go with a MAPS/IPv6 aware CPE which the customer pays for if they wish IPv6 connectivity(or during whatever slow trickle replacement methods you utilize). While waiting for the slow rollout, CGN would be an interim cost that would be acceptable. I'm not sure there is a reason for MAPS if you've already deployed CGN, though. I am sure Verizon did a lot of cost analysis. Jack .
RE: Verizon DSL moving to CGN
Can anyone from Verizon comment on what IP space that's being used for this? Or perhaps what the rDNS mask will look like? From an abuse perspective, knowing that an IP is being used for this can make the difference between traffic looking like abuse and traffic looking like multiple legitimate users. Malcolm Staudinger Information Security Analyst | EIS EarthLink -Original Message- From: cb.list6 [mailto:cb.li...@gmail.com] Sent: Saturday, April 06, 2013 6:24 PM To: nanog@nanog.org Subject: Verizon DSL moving to CGN Interesting. http://www22.verizon.com/support/residential/internet/highspeedinternet/ networking/troubleshooting/portforwarding/123897.htm
Re: Verizon DSL moving to CGN
CGN-like box. Yes, it's stateless. Doesn't matter, I still need to flow traffic through a dedicated box because MAP won't be implemented in my regular routers (if you know otherwise, please speak up). Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular routers that I know of - ASR9K and ASR1K. Without that, you are right that MAP wouldn't have been as beneficial as claimed. It's still NAT. Yes, assuming MAP-T. No, assuming, MAP-E Cheers, Rajiv -Original Message- From: Mikael Abrahamsson swm...@swm.pp.se Organization: People's Front Against WWW Date: Monday, April 8, 2013 6:01 AM To: Rajiv Asati raj...@cisco.com Cc: nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote: Thankfully, MAP is not CGN. Correctly stated, unlike DS-Lite, MAP doesn't require any CGN that causes the SP network to put up with the NAT state. This means that all the subsequent issues of CGN/DS-Lite no longer apply. For me as an operator, MAP is most likely going to be implemented in a CGN-like box. Yes, it's stateless. Doesn't matter, I still need to flow traffic through a dedicated box because MAP won't be implemented in my regular routers (if you know otherwise, please speak up). MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled access. MAP makes much more sense in any SP network having its internet customers do IPv4 address sharing and embrace IPv6. It's still NAT. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Verizon DSL moving to CGN
On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva) raj...@cisco.comwrote: Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular routers that I know of - ASR9K and ASR1K. Without that, you are right that MAP wouldn't have been as beneficial as claimed. glad it's cross platform... is it also IP encumbered so it'll remain just as 'cross platform' ?
Re: Verizon DSL moving to CGN
Tore is spot on. With MAP, you can use your regular routers, whether it is the Encap mode or Translation mode. One can decide between Encap mode and Translation mode of MAP per his/her environment/requirements. I do find -T mode preferable since it requires no changes to the transparent caching infrastructure or LI infrastructure or QOS policies (if used between CE and Border routers). One may refer to additional details here - http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_pap er_c11-558744-00.html#wp9000119 http://www.ciscoknowledgenetwork.com/files/300_11-06-2012-NGN-IPv4-Exhaust- IPv6-Strategy.pdf Cheers, Rajiv -Original Message- From: Tore Anderson t...@fud.no Date: Monday, April 8, 2013 6:29 AM To: Mikael Abrahamsson swm...@swm.pp.se Cc: Rajiv Asati raj...@cisco.com, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN * Mikael Abrahamsson On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote: MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled access. MAP makes much more sense in any SP network having its internet customers do IPv4 address sharing and embrace IPv6. It's still NAT. AIUI, the standards-track flavour of MAP, MAP-E, is *not* NAT - it is tunneling, pure encap/decap plus a clever way to calculate the outer IPv6 src/dst addresses from the inner IPv4 addresses and ports. The inner IPv4 packets are not modified by the centralised MAP tunneling routers, so there is no Network Address Translation being performed. The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44 component though, so there is some NAT involved in the overall solution, but it's pretty much the same as what we have in today's CPEs/HGWs. The only significant difference is that a MAP CPE must be prepared to not being able to use all the 65536 source ports. Tore
Re: Verizon DSL moving to CGN
Sam, What may make 'much more sense' in one network, doesn't necessarily make as much since in another network. As I understand it, MAP requires at least a software change on existing CPE, if not wholesale CPE change. Some providers may prefer to implement CGN instead if the capital outlay is less (and providing new CPE to customers through walkins or truck rolls can be problematic). I agree with you. Having said that, the way many ISPs are approaching the MAP deployment is by letting the new customers get the MAP capable CPE from the get go, while letting the existing customers' get their CPE routers upgraded when/if they need a truck roll or through regular SH (much like how Vonage does it). It is certainly very much possible to get MAP functionality by software upgrades, though the mileage may vary. What devices does Cisco support MAP on? Specifically, does the DPC3827 support it? MAP BR function is supported on ASR9K and ASR1K. I am not aware of MAP CE function support on DPC3827 CPE router. Cheers, Rajiv -Original Message- From: Sam Hayes Merritt, III s...@themerritts.org Date: Sunday, April 7, 2013 10:56 PM To: Rajiv Asati raj...@cisco.com Cc: nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled access. MAP makes much more sense in any SP network having its internet customers do IPv4 address sharing and embrace IPv6. What may make 'much more sense' in one network, doesn't necessarily make as much since in another network. As I understand it, MAP requires at least a software change on existing CPE, if not wholesale CPE change. Some providers may prefer to implement CGN instead if the capital outlay is less (and providing new CPE to customers through walkins or truck rolls can be problematic). Our plan for my company at this time is to deploy native IPv4+IPv6 to all customers. While we are doing that, continue discussions and testing with CGN providers so that when we are unable to obtain anymore IPv4 addresses, we can then deploy CGN. Our hope is that we never get to the point of having to go CGN but we have to be ready in case that day comes and have our implementation and opt-out (if available) processes ready. What devices does Cisco support MAP on? Specifically, does the DPC3827 support it? sam
Re: Verizon DSL moving to CGN
Like you, I would like to be optimistic about many v4-only apps and v4-only devices becoming dual-stack sooner than later. But knowing that a significant (50%+) of android devices may not support IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over the weekend) being v4-only) and may not be upgraded by their users to the right software, and that Skype etc. apps are out there, my optimism fades away. Cheers, Rajiv -Original Message- From: Owen DeLong o...@delong.com Date: Monday, April 8, 2013 1:38 AM To: Rajiv Asati raj...@cisco.com Cc: Fabien Delmotte fdelmot...@mac.com, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Apr 7, 2013, at 18:21 , Rajiv Asati (rajiva) raj...@cisco.com wrote: Dual-stack in the home networks will stay with us for a long time (beyond 2020!) until v4-only user devices and v4-only apps get refreshed. I disagree. I think that v4-only apps and devices will get relegated to being connected through v4-v6 adapter appliances until they are fixed. IPv4 is simply going to become far too expensive to maintain to be able to deliver it for residential pricing. Of course, this doesn't mean that the ISP access needs to stay dual-stack, thanks to MAP, 464XLAT etc. Right... Those are some of the ways that maintaining IPv4 will become so expensive. ;-) Owen
Re: Verizon DSL moving to CGN
Jack, I am assuming that you meant MAP, when you wrote MAPS. The larger issue I think with MAP is CPE support requirements. There are ISP layouts that use bridging instead of CPE routers (which was a long term design to support IPv6 without CPE replacements years later). CGN will handle the IPv4 issues in this setup just fine. Then there are I agree. Good point, btw. This is the classical ISP deployment model, in which the ISP would usually provide the layer2 modem, and let the customer get the retail CPE. those who have already deployed IPv6 capable CPEs with PPP or DHCP in a router configuration which does not have MAP support. Given the variety of CPE vendors that end up getting deployed over a longer period of time, it is easier and more cost effective to deploy CGN than try and replace all the CPEs. Seemingly so, until we start adding up the cost of - Logging infrastructure (setup mtc) - Static NAT Port forwarding (gaming, camera, etc.) - CGN redundancy load-sharing - design complexity (to maintain symmetry) - .. Given US$35/CPE, cost for replacements (not including deployment costs) for 20k users is US$700k. CGN gear suddenly doesn't seem so costly. Let's throw some numbers of the above costs and then we can do the apple-to-apple comparison. Else, you are right that CGN cost could be a lot less. Cheers, Rajiv -Original Message- From: Jack Bates jba...@brightok.net Date: Monday, April 8, 2013 10:23 AM To: Tore Anderson t...@fud.no Cc: nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On 4/8/2013 7:20 AM, Tore Anderson wrote: BTW. It is AIUI quite possible with MAP to provision a whole IPv4 address or even a prefix to the subscriber, thus also taking away the need for [srcport-restricted] NAPT44 in the CPE. The problem is NAPT44 in the CPE isn't enough. We are reaching the point that 1 IPv4 Address per customer won't accommodate user bases. The larger issue I think with MAP is CPE support requirements. There are ISP layouts that use bridging instead of CPE routers (which was a long term design to support IPv6 without CPE replacements years later). CGN will handle the IPv4 issues in this setup just fine. Then there are those who have already deployed IPv6 capable CPEs with PPP or DHCP in a router configuration which does not have MAP support. Given the variety of CPE vendors that end up getting deployed over a longer period of time, it is easier and more cost effective to deploy CGN than try and replace all the CPEs. Given US$35/CPE, cost for replacements (not including deployment costs) for 20k users is US$700k. CGN gear suddenly doesn't seem so costly. The only way I see it justifiable is if you haven't had IPv6 deployment in mind yet and you are having to replace every CPE for IPv6 support anyways, you might go with a MAPS/IPv6 aware CPE which the customer pays for if they wish IPv6 connectivity(or during whatever slow trickle replacement methods you utilize). While waiting for the slow rollout, CGN would be an interim cost that would be acceptable. I'm not sure there is a reason for MAPS if you've already deployed CGN, though. I am sure Verizon did a lot of cost analysis. Jack
Re: Verizon DSL moving to CGN
Chris, UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP encumbered? If so, the answer is Yes. v6 addressing doesn't need to change to accommodate this IPv4 A+P encoding. Cheers, Rajiv -Original Message- From: Christopher Morrow morrowc.li...@gmail.com Date: Monday, April 8, 2013 2:28 PM To: Rajiv Asati raj...@cisco.com Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular routers that I know of - ASR9K and ASR1K. Without that, you are right that MAP wouldn't have been as beneficial as claimed. glad it's cross platform... is it also IP encumbered so it'll remain just as 'cross platform' ?
Re: Verizon DSL moving to CGN
I think he means patent encumbered. On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote: Chris, UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP encumbered? If so, the answer is Yes. v6 addressing doesn't need to change to accommodate this IPv4 A+P encoding. Cheers, Rajiv -Original Message- From: Christopher Morrow morrowc.li...@gmail.com Date: Monday, April 8, 2013 2:28 PM To: Rajiv Asati raj...@cisco.com Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular routers that I know of - ASR9K and ASR1K. Without that, you are right that MAP wouldn't have been as beneficial as claimed. glad it's cross platform... is it also IP encumbered so it'll remain just as 'cross platform' ?
Re: Verizon DSL moving to CGN
Oh, it certainly is (per the IETF IPR rules). Thanks for the clarity, Chuck. Cheers, Rajiv -Original Message- From: Chuck Anderson c...@wpi.edu Date: Monday, April 8, 2013 3:18 PM To: Rajiv Asati raj...@cisco.com Cc: Christopher Morrow morrowc.li...@gmail.com, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN I think he means patent encumbered. On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote: Chris, UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP encumbered? If so, the answer is Yes. v6 addressing doesn't need to change to accommodate this IPv4 A+P encoding. Cheers, Rajiv -Original Message- From: Christopher Morrow morrowc.li...@gmail.com Date: Monday, April 8, 2013 2:28 PM To: Rajiv Asati raj...@cisco.com Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular routers that I know of - ASR9K and ASR1K. Without that, you are right that MAP wouldn't have been as beneficial as claimed. glad it's cross platform... is it also IP encumbered so it'll remain just as 'cross platform' ?
Re: Verizon DSL moving to CGN
Tore, I haven't tested, but I believe that if you were to hook up a standard Linux box to a ISP that provides /32 or shorter over MAP, you don't Yes, indeed. In fact, almost all of the MAP CE implementations (that I am aware of) are open source/linux based - http://enog.jp/~masakazu/vyatta/map/ http://mapt.ivi2.org:8039/readme.txt Cheers, Rajiv -Original Message- From: Tore Anderson t...@fud.no Date: Monday, April 8, 2013 8:20 AM To: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org Cc: Rajiv Asati raj...@cisco.com Subject: Re: Verizon DSL moving to CGN * Tore Anderson The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44 component though, so there is some NAT involved in the overall solution, but it's pretty much the same as what we have in today's CPEs/HGWs. The only significant difference is that a MAP CPE must be prepared to not being able to use all the 65536 source ports. BTW. It is AIUI quite possible with MAP to provision a whole IPv4 address or even a prefix to the subscriber, thus also taking away the need for [srcport-restricted] NAPT44 in the CPE. I find that the easiest way to visualise MAP is to take the 16 bits of TCP/UDP port space, and bolt it onto the end of the 32 bits of the IPv4 address space, for a total of 48 routable bits. So while the primary use case for MAP is to provision less than 32 bits to the individual customers (say a /34 - 4 subscribers per IPv4 address w/16k ports each), you can also give out a whole /32 or a /24 or whatever - perhaps only to the customers that are willing to pay for the privilege. I haven't tested, but I believe that if you were to hook up a standard Linux box to a ISP that provides /32 or shorter over MAP, you don't really need any special MAP support in the IP stack to make it go - you'd have to calculate the addresses to be used yourself, but once you've got them, you could just configure everything using standard ip tunnel/address commands. It's quite neat, I think. :-) Tore
Re: Verizon DSL moving to CGN
On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva) raj...@cisco.comwrote: Oh, it certainly is (per the IETF IPR rules). which rfcs? I can find a draft in softwire: http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01 and a reference to this in wikipedia: http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP which says: ...(MAP) is a Cisco IPv6 transition proposal... so.. err, we won't see this in juniper gear since: 1) not a standard 2) encumbered by IPR issues weee! Thanks for the clarity, Chuck. Cheers, Rajiv -Original Message- From: Chuck Anderson c...@wpi.edu Date: Monday, April 8, 2013 3:18 PM To: Rajiv Asati raj...@cisco.com Cc: Christopher Morrow morrowc.li...@gmail.com, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN I think he means patent encumbered. On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote: Chris, UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP encumbered? If so, the answer is Yes. v6 addressing doesn't need to change to accommodate this IPv4 A+P encoding. Cheers, Rajiv -Original Message- From: Christopher Morrow morrowc.li...@gmail.com Date: Monday, April 8, 2013 2:28 PM To: Rajiv Asati raj...@cisco.com Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular routers that I know of - ASR9K and ASR1K. Without that, you are right that MAP wouldn't have been as beneficial as claimed. glad it's cross platform... is it also IP encumbered so it'll remain just as 'cross platform' ?
Re: Verizon DSL moving to CGN
http://datatracker.ietf.org/ipr/search/?option=document_searchid_document_tag=draft-ietf-softwire-map http://datatracker.ietf.org/doc/draft-ietf-softwire-map/?include_text=1 On Mon, Apr 08, 2013 at 03:41:54PM -0400, Christopher Morrow wrote: On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva) raj...@cisco.comwrote: Oh, it certainly is (per the IETF IPR rules). which rfcs? I can find a draft in softwire: http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01 and a reference to this in wikipedia: http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP which says: ...(MAP) is a Cisco IPv6 transition proposal... so.. err, we won't see this in juniper gear since: 1) not a standard 2) encumbered by IPR issues weee! Thanks for the clarity, Chuck. Cheers, Rajiv -Original Message- From: Chuck Anderson c...@wpi.edu Date: Monday, April 8, 2013 3:18 PM To: Rajiv Asati raj...@cisco.com Cc: Christopher Morrow morrowc.li...@gmail.com, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN I think he means patent encumbered. On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote: Chris, UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP encumbered? If so, the answer is Yes. v6 addressing doesn't need to change to accommodate this IPv4 A+P encoding. Cheers, Rajiv -Original Message- From: Christopher Morrow morrowc.li...@gmail.com Date: Monday, April 8, 2013 2:28 PM To: Rajiv Asati raj...@cisco.com Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular routers that I know of - ASR9K and ASR1K. Without that, you are right that MAP wouldn't have been as beneficial as claimed. glad it's cross platform... is it also IP encumbered so it'll remain just as 'cross platform' ?
Re: Verizon DSL moving to CGN
Chris, That's an incorrect draft pointer. Here is the correct one - http://tools.ietf.org/html/draft-ietf-softwire-map tools.ietf.org/html/draft-ietf-softwire-map-t http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp And no, Cisco has no IPR on MAP wrt the above drafts. Cheers, Rajiv PS: Please do note that the IPRs mostly get nullified once they are through the IETF standards process. -Original Message- From: Christopher Morrow morrowc.li...@gmail.com Date: Monday, April 8, 2013 3:41 PM To: Rajiv Asati raj...@cisco.com Cc: Chuck Anderson c...@wpi.edu, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Oh, it certainly is (per the IETF IPR rules). which rfcs? I can find a draft in softwire: http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01 and a reference to this in wikipedia: http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP which says: ...(MAP) is a Cisco IPv6 transition proposal... so.. err, we won't see this in juniper gear since: 1) not a standard 2) encumbered by IPR issues weee! Thanks for the clarity, Chuck. Cheers, Rajiv -Original Message- From: Chuck Anderson c...@wpi.edu Date: Monday, April 8, 2013 3:18 PM To: Rajiv Asati raj...@cisco.com Cc: Christopher Morrow morrowc.li...@gmail.com, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN I think he means patent encumbered. On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote: Chris, UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP encumbered? If so, the answer is Yes. v6 addressing doesn't need to change to accommodate this IPv4 A+P encoding. Cheers, Rajiv -Original Message- From: Christopher Morrow morrowc.li...@gmail.com Date: Monday, April 8, 2013 2:28 PM To: Rajiv Asati raj...@cisco.com Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular routers that I know of - ASR9K and ASR1K. Without that, you are right that MAP wouldn't have been as beneficial as claimed. glad it's cross platform... is it also IP encumbered so it'll remain just as 'cross platform' ?
Re: Verizon DSL moving to CGN
In what sense do you mean that? The end-user IPv6 prefix certainly ties IPv4 and IPv6 together, hence the interest in the Light-Weight IPv4 over IPv6 alternative. Tom On 08/04/2013 3:13 PM, Rajiv Asati (rajiva) wrote: Chris, UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP encumbered? If so, the answer is Yes. v6 addressing doesn't need to change to accommodate this IPv4 A+P encoding. Cheers, Rajiv ...
need help about free bandwidth graph program
Hi all Do you know any opensource program bandwidthgraph by ipaddess? Thank you
Re: Verizon DSL moving to CGN
On Mon, Apr 8, 2013 at 3:48 PM, Rajiv Asati (rajiva) raj...@cisco.comwrote: Chris, That's an incorrect draft pointer. Here is the correct one - http://tools.ietf.org/html/draft-ietf-softwire-map tools.ietf.org/html/draft-ietf-softwire-map-t http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp great, but still a draft, not an official standard. And no, Cisco has no IPR on MAP wrt the above drafts. 'yet'... they don't have to officially declare until WGLC... and REALLY not until the draft is sent up to the IESG, but doing it early is certainly nice so that the WG has an opportunity to say: yea, IPR here is going to cause a problem with interop/etc. Cheers, Rajiv PS: Please do note that the IPRs mostly get nullified once they are through the IETF standards process. that's not been my experience.. see flow-spec for a great example. 'mostly nullified' is .. disingenuous at best. -Original Message- From: Christopher Morrow morrowc.li...@gmail.com Date: Monday, April 8, 2013 3:41 PM To: Rajiv Asati raj...@cisco.com Cc: Chuck Anderson c...@wpi.edu, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Oh, it certainly is (per the IETF IPR rules). which rfcs? I can find a draft in softwire: http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01 and a reference to this in wikipedia: http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP which says: ...(MAP) is a Cisco IPv6 transition proposal... so.. err, we won't see this in juniper gear since: 1) not a standard 2) encumbered by IPR issues weee! Thanks for the clarity, Chuck. Cheers, Rajiv -Original Message- From: Chuck Anderson c...@wpi.edu Date: Monday, April 8, 2013 3:18 PM To: Rajiv Asati raj...@cisco.com Cc: Christopher Morrow morrowc.li...@gmail.com, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN I think he means patent encumbered. On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote: Chris, UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP encumbered? If so, the answer is Yes. v6 addressing doesn't need to change to accommodate this IPv4 A+P encoding. Cheers, Rajiv -Original Message- From: Christopher Morrow morrowc.li...@gmail.com Date: Monday, April 8, 2013 2:28 PM To: Rajiv Asati raj...@cisco.com Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular routers that I know of - ASR9K and ASR1K. Without that, you are right that MAP wouldn't have been as beneficial as claimed. glad it's cross platform... is it also IP encumbered so it'll remain just as 'cross platform' ?
Re: need help about free bandwidth graph program
Maybe http://en.wikipedia.org/wiki/Cacti_(software) would do what you want. www: http://www.cacti.net/index.php On Mon, Apr 8, 2013 at 3:51 PM, Deric Kwok deric.kwok2...@gmail.com wrote: Hi all Do you know any opensource program bandwidthgraph by ipaddess? Thank you -- ~ Andrew lathama Latham lath...@gmail.com http://lathama.net ~
Re: need help about free bandwidth graph program
Ntop has my vote. Nprobe is a great bolt on for sans NetFlow environments. Sent from my T-Mobile 4G LTE Device Original message From: Andrew Latham lath...@gmail.com Date: 04/08/2013 1:07 PM (GMT-08:00) To: Deric Kwok deric.kwok2...@gmail.com Cc: nanog list nanog@nanog.org Subject: Re: need help about free bandwidth graph program Maybe http://en.wikipedia.org/wiki/Cacti_(software) would do what you want. www: http://www.cacti.net/index.php On Mon, Apr 8, 2013 at 3:51 PM, Deric Kwok deric.kwok2...@gmail.com wrote: Hi all Do you know any opensource program bandwidthgraph by ipaddess? Thank you -- ~ Andrew lathama Latham lath...@gmail.com http://lathama.net ~
Re: need help about free bandwidth graph program
I'm not sure of your specific application, but it sounds to me like netflow/sflow exports would be the most scalable way to do this. For small applications, ntop or bandwidthd can do this. http://www.ntop.org/products/ntop/ http://bandwidthd.sourceforge.net/ Cheers, jof On Mon, Apr 8, 2013 at 12:51 PM, Deric Kwok deric.kwok2...@gmail.com wrote: Hi all Do you know any opensource program bandwidthgraph by ipaddess? Thank you
Re: Verizon DSL moving to CGN
Once upon a time, Rajiv Asati (rajiva) raj...@cisco.com said: But knowing that a significant (50%+) of android devices may not support IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over the weekend) being v4-only) and may not be upgraded by their users to the right software, and that Skype etc. apps are out there, my optimism fades away. Yeah, Samsung is screwy on Android+IPv6. My (less than 6 month old) Samsung phone with Android 4.0 gets an IPv6 address (autoconfigured) but does not add an IPv6 default route, so it can't reach the IPv6 Internet over wi-fi. IIRC when I enabled T-Mobile's IPv6 APN, it did handle IPv6 over the cell network okay. My generic Chinese import Android 4.0 tablet works just fine with IPv6, as did my old HTC/T-Mobile G2 (wi-fi only). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Announcing BGP-SRx 0.3.0 service release
This is to announce the BGP Secure Router Extension (BGP-SRx) Version 0.3 Prototype Implementation. This release includes extensive performance and robustness improvements, multi router support, re-design/re-write of the Quagga integration, and many bug fixes. BGP-SRx is an open source reference implementation and research platform for investigating emerging BGP security extensions and supporting protocols. The BGP-SRx suite consists of three parts: (1) SRx Server, (2) SRx API, and (3) Quagga-SRx (which integrates the SRx API into the Quagga router). The focus is on origin validation, although it is designed to be extended to path validation. Stub functionality for path validation is included in this version. Additionally, this release contains an SRx client/server test harnesses and a simple RPKI validation cache simulator (VCS). The VCS allows to manually feed ROA information into BGP-SRx server using the RPKI to Router protocol (rfc6810) as well as WireShark modules for debugging. For more information on BGP-SRx, and to download the prototype and tools, see: http://www-x.antd.nist.gov/bgpsrx/ Comments and feedback about BGP-SRx are welcome. See the project page for details. Thanks, Oliver Borchert - Oliver Borchert, Computer Scientist National Institute of Standards and Technology (Phone) 301.975.4856 , (Fax) 301.975.6238 - Oliver Borchert, Computer Scientist National Institute of Standards and Technology (Phone) 301.975.4856 , (Fax) 301.975.6238
Re: need help about free bandwidth graph program
On 2013-04-08, Andrew Latham lath...@gmail.com sent: Maybe http://en.wikipedia.org/wiki/Cacti_(software) would do what you want. www: http://www.cacti.net/index.php If we're talking SNMP counters, Observium might be worth a look. http://www.observium.org/ -- Chip Marshall c...@2bithacker.net http://2bithacker.net/ pgp19wf8e7vuR.pgp Description: PGP signature
Re: need help about free bandwidth graph program
Do you know any opensource program bandwidthgraph by ipaddess? What are you trying to accomplish? sam
Re: need help about free bandwidth graph program
If you can export netflow you can use the FlowViewer / flow-tools / SiLK open-source toolset. It can track bandwidth over time according to any filter you provide it, including IP address. User interface includes an updating dashboard. http://sourceforge.net/projects/flowviewer Joe From: Deric Kwok deric.kwok2...@gmail.com To: nanog list nanog@nanog.org Date: 04/08/2013 03:57 PM Subject:need help about free bandwidth graph program Hi all Do you know any opensource program bandwidthgraph by ipaddess? Thank you
Re: Verizon DSL moving to CGN
We got this modem and router all in one box from Comcast directly. And by the way, home use routers don't assign 10.0.0.0 numbers. Joe Sent from my iPhone On Apr 7, 2013, at 9:11 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Nope. Comcast is not using any CGN, as much as I know. Is your MacBook directly connected to the modem or a router? I presume the latter. Cheers, Rajiv Sent from my Phone On Apr 7, 2013, at 11:47 AM, Huasong Zhou huas...@kalorama.com wrote: I think Comcast is using CGN too!!! My IP address displayed on my MacBook is in the 10.0.0.0/8 range, and ARIN website can't determine my IP address either. Joe Sent from my iPhone On Apr 6, 2013, at 9:33 PM, Joshua Smith juice...@gmail.com wrote: Very interesting indeed. Way to do the right thing here Verizon. This may be the first time I've been happy to be a Comcast customer. -- Josh Smith kD8HRX email/jabber: juice...@gmail.com Phone: 304.237.9369(c) Sent from my iPad On Apr 6, 2013, at 9:24 PM, cb.list6 cb.li...@gmail.com wrote: Interesting. http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
Re: Verizon DSL moving to CGN
Chris, Your points are well taken. Cheers, Rajiv -Original Message- From: Christopher Morrow morrowc.li...@gmail.com Date: Monday, April 8, 2013 3:57 PM To: Rajiv Asati raj...@cisco.com Cc: Chuck Anderson c...@wpi.edu, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Mon, Apr 8, 2013 at 3:48 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Chris, That's an incorrect draft pointer. Here is the correct one - http://tools.ietf.org/html/draft-ietf-softwire-map tools.ietf.org/html/draft-ietf-softwire-map-t http://tools.ietf.org/html/draft-ietf-softwire-map-t http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp great, but still a draft, not an official standard. And no, Cisco has no IPR on MAP wrt the above drafts. 'yet'... they don't have to officially declare until WGLC... and REALLY not until the draft is sent up to the IESG, but doing it early is certainly nice so that the WG has an opportunity to say: yea, IPR here is going to cause a problem with interop/etc. Cheers, Rajiv PS: Please do note that the IPRs mostly get nullified once they are through the IETF standards process. that's not been my experience.. see flow-spec for a great example. 'mostly nullified' is .. disingenuous at best. -Original Message- From: Christopher Morrow morrowc.li...@gmail.com Date: Monday, April 8, 2013 3:41 PM To: Rajiv Asati raj...@cisco.com Cc: Chuck Anderson c...@wpi.edu, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Oh, it certainly is (per the IETF IPR rules). which rfcs? I can find a draft in softwire: http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01 http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01 and a reference to this in wikipedia: http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#MAP which says: ...(MAP) is a Cisco IPv6 transition proposal... so.. err, we won't see this in juniper gear since: 1) not a standard 2) encumbered by IPR issues weee! Thanks for the clarity, Chuck. Cheers, Rajiv -Original Message- From: Chuck Anderson c...@wpi.edu Date: Monday, April 8, 2013 3:18 PM To: Rajiv Asati raj...@cisco.com Cc: Christopher Morrow morrowc.li...@gmail.com, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN I think he means patent encumbered. On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote: Chris, UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP encumbered? If so, the answer is Yes. v6 addressing doesn't need to change to accommodate this IPv4 A+P encoding. Cheers, Rajiv -Original Message- From: Christopher Morrow morrowc.li...@gmail.com Date: Monday, April 8, 2013 2:28 PM To: Rajiv Asati raj...@cisco.com Cc: Mikael Abrahamsson swm...@swm.pp.se, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular routers that I know of - ASR9K and ASR1K. Without that, you are right that MAP wouldn't have been as beneficial as claimed. glad it's cross platform... is it also IP encumbered so it'll remain just as 'cross platform' ?
Re: Verizon DSL moving to CGN
- Original Message - From: Huasong Zhou huas...@kalorama.com We got this modem and router all in one box from Comcast directly. And by the way, home use routers don't assign 10.0.0.0 numbers. I have seen consumer NAT routers assign addresses in all three RFC1918 blocks, though I couldn't cite particular models for you. 10./ is less common than 172./, but not impossible. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Verizon DSL moving to CGN
On Apr 8, 2013, at 07:58 , joel jaeggli joe...@bogus.com wrote: On 4/8/13 7:23 AM, Jack Bates wrote: On 4/8/2013 7:20 AM, Tore Anderson wrote: BTW. It is AIUI quite possible with MAP to provision a whole IPv4 address or even a prefix to the subscriber, thus also taking away the need for [srcport-restricted] NAPT44 in the CPE. The problem is NAPT44 in the CPE isn't enough. We are reaching the point that 1 IPv4 Address per customer won't accommodate user bases. That happened a long time ago. I realize the people like to think of wireless providers as different, they really aren't. A big chuck of our mobile gaming customers come to us via carrier operated nat translators. Some of them now come to us via ipv6, most do not. The larger issue I think with MAP is CPE support requirements. There are ISP layouts that use bridging instead of CPE routers (which was a long term design to support IPv6 without CPE replacements years later). CGN will handle the IPv4 issues in this setup just fine. Then there are those who have already deployed IPv6 capable CPEs with PPP or DHCP in a router configuration which does not have MAP support. Given the variety of CPE vendors that end up getting deployed over a longer period of time, it is easier and more cost effective to deploy CGN than try and replace all the CPEs. Given US$35/CPE, cost for replacements (not including deployment costs) for 20k users is US$700k. CGN gear suddenly doesn't seem so costly. The only way I see it justifiable is if you haven't had IPv6 deployment in mind yet and you are having to replace every CPE for IPv6 support anyways, you might go with a MAPS/IPv6 aware CPE which the customer pays for if they wish IPv6 connectivity(or during whatever slow trickle replacement methods you utilize). While waiting for the slow rollout, CGN would be an interim cost that would be acceptable. I'm not sure there is a reason for MAPS if you've already deployed CGN, though. I am sure Verizon did a lot of cost analysis. Jack There is actually a key difference. In the US, at least, everyone is used to the cellular networks mostly sucking. They are willing to put up with far more degraded service over wireless than they will tolerate on a wired connection. You and I and everyone else on this list realize that this is complete BS, but the majority of the general public tolerates it, so it persists. Owen
Re: Verizon DSL moving to CGN
I think what that screenshot is saying is that after you deploy MAP, then if you stop using it the IPv6 addresses don't need to change. I would assume you're not saying that you can take your IPv6 addresses as you find them and interpret them as MAP End-user prefixes. Tom On 08/04/2013 5:38 PM, Rajiv Asati (rajiva) wrote: Hi Tom, Good question. The End-user IPv6 prefix can be constructed using whatever techniques independent of MAP etc. in any deployment requiring IPv4 address sharing. What is interesting is that the MAP enabled CPE could parse certain bits of that IPv6 prefix to mean something for MAP. That's it. Attached is a screenshot to illustrate this very point. Cheers, Rajiv -Original Message- From: Tom Taylor tom.taylor.s...@gmail.com Date: Monday, April 8, 2013 3:48 PM To: nanog@nanog.org nanog@nanog.org Subject: Re: Verizon DSL moving to CGN In what sense do you mean that? The end-user IPv6 prefix certainly ties IPv4 and IPv6 together, hence the interest in the Light-Weight IPv4 over IPv6 alternative. Tom On 08/04/2013 3:13 PM, Rajiv Asati (rajiva) wrote: Chris, UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP encumbered? If so, the answer is Yes. v6 addressing doesn't need to change to accommodate this IPv4 A+P encoding. Cheers, Rajiv ...
Re: Verizon DSL moving to CGN
On Apr 8, 2013, at 11:54 , Rajiv Asati (rajiva) raj...@cisco.com wrote: Like you, I would like to be optimistic about many v4-only apps and v4-only devices becoming dual-stack sooner than later. But knowing that a significant (50%+) of android devices may not support IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over the weekend) being v4-only) and may not be upgraded by their users to the right software, and that Skype etc. apps are out there, my optimism fades away. The upgrade problem isn't that hard to solve. As soon as users want to use something that doesn't work without the upgrade, the upgrades get installed. Apple does a great job of this... Every time they release an iOS upgrade I really don't want, they manage to also release an update to software that I do care about. That software update inherently requires me to accept the iOS upgrade. Owen
Re: Verizon DSL moving to CGN
On Apr 7, 2013, at 18:45 , Huasong Zhou huas...@kalorama.com wrote: We got this modem and router all in one box from Comcast directly. And by the way, home use routers don't assign 10.0.0.0 numbers. Some do. Owen Joe Sent from my iPhone On Apr 7, 2013, at 9:11 PM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Nope. Comcast is not using any CGN, as much as I know. Is your MacBook directly connected to the modem or a router? I presume the latter. Cheers, Rajiv Sent from my Phone On Apr 7, 2013, at 11:47 AM, Huasong Zhou huas...@kalorama.com wrote: I think Comcast is using CGN too!!! My IP address displayed on my MacBook is in the 10.0.0.0/8 range, and ARIN website can't determine my IP address either. Joe Sent from my iPhone On Apr 6, 2013, at 9:33 PM, Joshua Smith juice...@gmail.com wrote: Very interesting indeed. Way to do the right thing here Verizon. This may be the first time I've been happy to be a Comcast customer. -- Josh Smith kD8HRX email/jabber: juice...@gmail.com Phone: 304.237.9369(c) Sent from my iPad On Apr 6, 2013, at 9:24 PM, cb.list6 cb.li...@gmail.com wrote: Interesting. http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
Re: Verizon DSL moving to CGN
On 4/8/13 5:55 PM, Owen DeLong wrote: On Apr 7, 2013, at 18:45 , Huasong Zhou huas...@kalorama.com wrote: We got this modem and router all in one box from Comcast directly. And by the way, home use routers don't assign 10.0.0.0 numbers. Some do. ATT U-verse used to have 10.0.0.0/8 as an option until a firmware update removed that capability. My bet is on CGN prep work. ~Seth
Re: Verizon DSL moving to CGN
Hi Tom, The key take-away is that MAP doesn't _necessarily_ require IPv6 prefix to be constructed in a special way (so as to encode the IPv4 address inside it). Please see more inline, I think what that screenshot is saying is that after you deploy MAP, then if you stop using it the IPv6 addresses don't need to change. Yes. I would assume you're not saying that you can take your IPv6 addresses as you find them and interpret them as MAP End-user prefixes. It can work even in that realm as well (IPv6 PD assumed). There are pros cons of doing this, suffice to say. Cheers, Rajiv -Original Message- From: Tom Taylor tom.taylor.s...@gmail.com Date: Monday, April 8, 2013 8:51 PM To: Rajiv Asati raj...@cisco.com Cc: nanog@nanog.org nanog@nanog.org Subject: Re: Verizon DSL moving to CGN I think what that screenshot is saying is that after you deploy MAP, then if you stop using it the IPv6 addresses don't need to change. I would assume you're not saying that you can take your IPv6 addresses as you find them and interpret them as MAP End-user prefixes. Tom On 08/04/2013 5:38 PM, Rajiv Asati (rajiva) wrote: Hi Tom, Good question. The End-user IPv6 prefix can be constructed using whatever techniques independent of MAP etc. in any deployment requiring IPv4 address sharing. What is interesting is that the MAP enabled CPE could parse certain bits of that IPv6 prefix to mean something for MAP. That's it. Attached is a screenshot to illustrate this very point. Cheers, Rajiv -Original Message- From: Tom Taylor tom.taylor.s...@gmail.com Date: Monday, April 8, 2013 3:48 PM To: nanog@nanog.org nanog@nanog.org Subject: Re: Verizon DSL moving to CGN In what sense do you mean that? The end-user IPv6 prefix certainly ties IPv4 and IPv6 together, hence the interest in the Light-Weight IPv4 over IPv6 alternative. Tom On 08/04/2013 3:13 PM, Rajiv Asati (rajiva) wrote: Chris, UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP encumbered? If so, the answer is Yes. v6 addressing doesn't need to change to accommodate this IPv4 A+P encoding. Cheers, Rajiv ...
Re: Verizon DSL moving to CGN
I agree. Apple does it really well, no doubt about it. This is because they control both the software and hardware. Google/Android çan not do it well enough, since the Android OS version compatibility with the hardware is somewhat dictated by the hardware manufacturer. This isn't always helpful. :-( For ex, there are numerous android apps that are not supported on many android devices. :=( Anyway, this is why I think that dual-stack home networks (and UEs) will be with us for a long time. Cheers, Rajiv -Original Message- From: Owen DeLong o...@delong.com Date: Monday, April 8, 2013 8:52 PM To: Rajiv Asati raj...@cisco.com Cc: Fabien Delmotte fdelmot...@mac.com, nanog list nanog@nanog.org Subject: Re: Verizon DSL moving to CGN On Apr 8, 2013, at 11:54 , Rajiv Asati (rajiva) raj...@cisco.com wrote: Like you, I would like to be optimistic about many v4-only apps and v4-only devices becoming dual-stack sooner than later. But knowing that a significant (50%+) of android devices may not support IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over the weekend) being v4-only) and may not be upgraded by their users to the right software, and that Skype etc. apps are out there, my optimism fades away. The upgrade problem isn't that hard to solve. As soon as users want to use something that doesn't work without the upgrade, the upgrades get installed. Apple does a great job of this... Every time they release an iOS upgrade I really don't want, they manage to also release an update to software that I do care about. That software update inherently requires me to accept the iOS upgrade. Owen
Re: Verizon DSL moving to CGN
On Mon, Apr 8, 2013 at 11:23 PM, Rajiv Asati (rajiva) raj...@cisco.comwrote: For ex, there are numerous android apps that are not supported on many android devices. :=( I think this is actually up to the developer of the APP not the hardware nor OS manufacturer.
