Re: Verizon DSL moving to CGN
On Sun, 07 Apr 2013 01:40:09 -0400, Christopher Morrow said: I wonder how much more painful just upgrading the dsl plant to support v6 would be vs deploying the cgn equipment and funneling users through that :( The answer depends on whether the person making the decision thinks they'll have left the company before the IPv6 birds come home to roost. ;) pgpaKqY0d0nVi.pgp Description: PGP signature
Re: Verizon DSL moving to CGN
On Sun, 7 Apr 2013, Christopher Morrow wrote: I wonder how much more painful just upgrading the dsl plant to support v6 would be vs deploying the cgn equipment and funneling users through that :( IPv6 deployment is not a short term solution to IPv4 address depletion. Would you be less upset if there was IPv6 access and CPE based DS Lite (ie your IPv4 is still CGN:ed, just in a different way)? CGN is here to stay for IPv4. The solution for long term Internet growth is IPv6. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Verizon DSL moving to CGN
CGN is just a solution to save time, it is not a transition mechanism through IPv6 At the end (IPv6 at home) you will need at list : Dual stack or NAT64/ DNS64 My 2 cents On Apr 7, 2013, at 8:42 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Sun, 7 Apr 2013, Christopher Morrow wrote: I wonder how much more painful just upgrading the dsl plant to support v6 would be vs deploying the cgn equipment and funneling users through that :( IPv6 deployment is not a short term solution to IPv4 address depletion. Would you be less upset if there was IPv6 access and CPE based DS Lite (ie your IPv4 is still CGN:ed, just in a different way)? CGN is here to stay for IPv4. The solution for long term Internet growth is IPv6. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Verizon DSL moving to CGN
On Sun, 7 Apr 2013, Fabien Delmotte wrote: CGN is just a solution to save time, it is not a transition mechanism through IPv6 At the end (IPv6 at home) you will need at list : Dual stack or NAT64/ DNS64 CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the water without other mechanisms (464XLAT or alike). My point is that people seem to scoff at CGN. There is nothing stopping anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address exhaustion), then giving dual stack for end users can be done at any time. Face it, we're running out of IPv4 addresses. For basic Internet subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a completely different problem that has little bearing on CGN or not for IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also CGN. I'm ok with people complaining about lack of IPv6 deployment, but I don't understand people complaining about CGN. What's the alternative? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Verizon DSL moving to CGN
Well if the RFCs would just be set in stone already like Moses's 10 commandments and if the programmers would actually start writing code for v6 and if the web site hosting servers would at least have dual stack enabled on them it would be great. But till then we just change a RFC here, band-aid IPv4 there and wait till everything reaches critical mass and comes crashing on our heads. On 4/7/2013 5:38 AM, Jay Ashworth wrote: - Original Message - From: cb.list6 cb.li...@gmail.com Interesting. http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm What I find amusing is how they call it Carrier Grade NAT one time, and then switch to calling it Carrier Grade Network, thereby making it sound all cool and better and stuff... Cheers, -- jra
Re: Verizon DSL moving to CGN
Jimmy Hess mysi...@gmail.com writes: On 4/6/13, Matthew Kaufman matt...@matthew.at wrote: On 4/6/2013 6:24 PM, cb.list6 wrote: I'd love to see a CGN box that is cheaper than IPv4 addresses currently are on the transfer market. You mean like a few linux servers running iptables nat-masquerade? You think the Carrier Grade in Carrier Grade NAT isn't just a rhetorically constructed distraction, from the fact that simple NAT may be implemented, and yeah, end users are certain to experience annoyances, either way... Forget about the annoying users part; the carrier-grade part of CGN is all about not annoying the service provider. As far as I'm aware, iptables does not include deterministic port translation based on source address, nor easy-to-configure hooks for CALEA [*]. It may well turn out that once one factors in support your costs are higher with large scale NAT-on-Linux than if you'd sucked it up and coughed up a quarter mil for an appliance. -r [*] I'd love to hear that I'm wrong on this count, but a how-to document that explains how one can lovingly handcraft such a thing as opposed to a special refactored distro that's ready to plug-and-chug appliance style will only serve to reinforce my assertion.
Re: Verizon DSL moving to CGN
On Sun, 07 Apr 2013 13:54:04 +0300, Alex said: Well if the RFCs would just be set in stone already like Moses's 10 commandments and if the programmers would actually start writing code for v6 and if the web site hosting servers would at least have dual stack enabled on them it would be great. But till then we just change a RFC here, band-aid IPv4 there and wait till everything reaches critical mass and comes crashing on our heads. I find it interesting that you complain about a 15 year old protocol not being set in stone, and cite that as a reason for no code getting done. But the solution is to take advantage of the fact that the 30 year old predecessor isn't set in stone either... (And there's no reason that programmers can't be writing code - RFC3542 came out in May 2003) pgp27wjvg38nA.pgp Description: PGP signature
Re: Verizon DSL moving to CGN
* Mikael Abrahamsson My point is that people seem to scoff at CGN. There is nothing stopping anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address exhaustion), then giving dual stack for end users can be done at any time. Face it, we're running out of IPv4 addresses. For basic Internet subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a completely different problem that has little bearing on CGN or not for IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also CGN. I'm ok with people complaining about lack of IPv6 deployment, but I don't understand people complaining about CGN. What's the alternative? Technically I agree with all of the above. However, going for the NAT444 flavour of CGN might well delay or lower the perceived importance of IPv6 deployment within an ISP. The immediate problem is IPv4 service continuity, and if that is to be accomplished without IPv6 being part of it, it's easy to postpone doing anything about IPv6. I went to an interesting presentation from Kabel Deutschland last month, who have deployed DS-Lite to their residential subscribers. One of the messages was that once the decision was made to implement DS-Lite to deal with IPv4 exhaustion, there was no problem getting the necessary support to deploy IPv6 - it was no longer a separate and non-revenue-generating problem, but an essential building block needed for their IPv4 service continuity. (MAP and 464XLAT would yield the same effect, of course.) To answer your earlier question - yes, I'd very much prefer to have DS-Lite over NAT444, because only the former will ensure that I get native IPv6 once my native IPv4 gets taken away. With NAT444, I'm no closer to having IPv6 than I was before NAT444. That said, there are of course some things that may make anything except NAT444 undeployable. Verizon might have old DSLAMs that cannot deal with IPv6, or customer-controlled/owned (layer-3) HGWs. If so, their hands are tied. -- Tore Anderson
Re: NANOG Digest, Vol 63, Issue 29
In MPLS network when we speak of utilization is 50% between 2 points in a circuit , What does it mean and how can I measure it ? Sent from my BlackBerry® via Smartfren EVDO Network -Original Message- From: nanog-requ...@nanog.org Date: Sun, 07 Apr 2013 02:11:21 To: nanog@nanog.org Reply-To: nanog@nanog.org Subject: NANOG Digest, Vol 63, Issue 29 Send NANOG mailing list submissions to nanog@nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-requ...@nanog.org You can reach the person managing the list at nanog-ow...@nanog.org When replying, please edit your Subject line so it is more specific than Re: Contents of NANOG digest... Today's Topics: 1. Re: 30% packet loss between cox.net and hetzner.de, possibly at tinet.net (Denys Fedoryshchenko) 2. Verizon DSL moving to CGN (cb.list6) 3. Re: Verizon DSL moving to CGN (Joshua Smith) 4. Re: Verizon DSL moving to CGN (Oliver Garraux) 5. Re: ICMP Redirect on Resolvers (Jimmy Hess) 6. Re: Verizon DSL moving to CGN (Derek Ivey) 7. Re: Verizon DSL moving to CGN (Constantine A. Murenin) -- Message: 1 Date: Sun, 07 Apr 2013 03:09:00 +0300 From: Denys Fedoryshchenko de...@visp.net.lb To: Constantine A. Murenin muren...@gmail.com Cc: nanog@nanog.org Subject: Re: 30% packet loss between cox.net and hetzner.de, possibly at tinet.net Message-ID: d453f32ec9779702cd8bc18dd6f9e...@visp.net.lb Content-Type: text/plain; charset=UTF-8; format=flowed On 2013-04-07 02:20, Constantine A. Murenin wrote: Although hetzner.de claims that this whole loss is outside of their own network, I'm inclined to deduce that the loss might actually be concentrated on their own KPN / eurorings.net router -- kpn-gw.hetzner.de (134.222.107.21), and perhaps occurs only in one direction. I think too. Btw as i said, have host on tinet, and it is 100% clear from EC2. So seems tinet is fine for sure. HOST: ip-10-203-61-XSnt Rcv Loss% Best Gmean Avg Wrst StDev 1.|-- ip-10-203-60-2.ec2.internal 6060 0.0% 0.3 0.6 1.1 19.1 2.7 2.|-- ip-10-1-36-21.ec2.internal 6060 0.0% 0.4 0.6 0.8 9.3 1.3 3.|-- ip-10-1-34-0.ec2.internal 6060 0.0% 0.4 0.7 1.0 14.5 2.0 4.|-- 100.64.20.436060 0.0% 0.4 0.6 0.6 2.0 0.2 5.|-- ??? 60 0 100.0 0.0 0.0 0.0 0.0 0.0 6.|-- ??? 60 0 100.0 0.0 0.0 0.0 0.0 0.0 7.|-- ??? 60 0 100.0 0.0 0.0 0.0 0.0 0.0 8.|-- 100.64.16.157 6060 0.0% 0.5 2.4 9.7 68.8 16.1 9.|-- 72.21.222.154 6060 0.0% 1.5 1.9 2.6 36.4 4.8 10.|-- 72.21.220.466060 0.0% 1.5 2.1 3.3 59.2 7.6 11.|-- xe-7-2-0.was10.ip4.tinet.net6060 0.0% 1.6 2.1 2.6 17.2 3.1 12.|-- xe-0-1-0.fra23.ip4.tinet.net6060 0.0% 92.2 92.8 92.8 104.3 1.9 13.|-- ge-1-1-0.pr1.g310.fra.de.eurotransit.net6060 0.0% 92.2 93.1 93.2 112.8 3.3 14.|-- ??? 60 0 100.0 0.0 0.0 0.0 0.0 0.0 last hop icmp blocked, it is my host Although there is no traffic loss from he.net if you try to traceroute the router itself (I'm not sure what that means, though, other than a potential attack vector from exposing a router globally like that): I don't think there is attack vector, proper control plane ACL will make them safe. I've been a fan of hetzner.de, but I think it's staggering that they won't do anything about this huge and persistent packet loss. Indeed, i noticed that transfers from EC2 are terrible last days to Hetzner. Maybe worth to open topic at www.webhostingtalk.com ? Best regards, Constantine. --- Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L. -- Message: 2 Date: Sat, 6 Apr 2013 18:24:10 -0700 From: cb.list6 cb.li...@gmail.com To: nanog@nanog.org Subject: Verizon DSL moving to CGN Message-ID: cad6ajgtmz-rpx8uox7qnpqr8x3esqeo34m+6epnquumnzdl...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Interesting. http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm -- Message: 3 Date: Sat, 6 Apr 2013 21:32:47 -0400 From: Joshua Smith juice...@gmail.com To: nanog@nanog.org nanog@nanog.org Subject: Re: Verizon DSL moving to CGN Message-ID:
Re: Verizon DSL moving to CGN
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
* Mikael Abrahamsson Otoh, ARIN isn't exhausted yet so getting IPv4 addresses there should still be a lot cheaper than doing CGN? From what I hear several ISPs in the ARIN region prefer to obtain second-hand IPv4 addresses (or deploy CGN boxes) over requesting addresses directly from ARIN, and the reason is that ARIN, per policy, will only give its members addresses to cover three months' worth of consumption, and that this period is simply too short for the allocation to be operationally useful, especially for large organisations. I have an anecdote to share here: A while back, a techie from a large organisation in the RIPE region told me that from their point of view, the RIPE NCC was effectively depleted once they implemented the three-month period for allocations on the 1st of July 2011, because they needed more than three months to actually put a new allocation in production - hence they couldn't justify anything any longer. When transferring, on the other hand, ARIN's policies allows for obtaining up to 24 months' worth of space. This gives longer-term operational predictability, which may easily justify the cost of the addresses themselves. Same thing goes for deploying CGNs instead - the organisation is then free to plan as far ahead as it feels like, without being constrained by ARIN policies. That has a value, possibly more than the cost of the CGN boxes themselves. Tore
Re: Verizon DSL moving to CGN
On Sat, 6 Apr 2013, Derek Ivey wrote: It would be nice to get an update from them regarding their IPv6 plans. Their IPv6 support page still says they will start deploying 3Q12 :(. I've been trying to get some information from internal contacts, but so far, no go. jms
Open Resolver Dataset Update
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. Some raw stats are also available via the 'breakdown' link on the main site. If you operate a DNS server, or have an internal group that does, please take a moment and review your networks. If you email me in private from a corporate address for your ASN, I can give you access to a per-ASN report. Due to a change in methodology, I have increased the number of servers observed from 27.2 million to 30.2 million hosts. 2013-04-07 results 30269218 servers responded to our udp/53 probe 731040 servers responded from a different IP than probed 25298074 gave the 'correct' answer to my A? for the DNS name queried. 13840790 responded from a source port other than udp/53 27145699 responses had recursion-available bit set. 2761869 returned REFUSED In addition, please do continue to deploy BCP-38 to prevent spoofing wherever possible. I know at $dayjob we have been auditing this and increased the number of customer interfaces that can not spoof. - Jared
Re: Verizon DSL moving to CGN
Would you be less upset if there was IPv6 access and CPE based DS Lite ds lite, nat in the core and cpe forklift. one of the worst mechanisms. randy
Re: ICMP Redirect on Resolvers
On Apr 6, 2013, at 16:03 , valdis.kletni...@vt.edu wrote:
On Sat, 06 Apr 2013 10:38:06 -0400, shawn wilson said:
What would break if u dropped all ICMP packets with redirects on public
facing boxes?
Presumably nothing, as long as you guaranteed that your IP address, netmask,
and routes actually match the reality of your network configuration. In that
case, you shouldn't see any valid ICMP redirects. They're there mostly so
things kind-of-sort-of work even if you botch it (so for instance, even if you
whiff your default route accidentally, you can still ssh in from Tokyo and fix
it).
Not entirely true.
They also cover the case where there are two (or more) routers on the
network and you don't want to have to configure more specific routes
on all your workstations.
For example, network B has routers [A] and [C]. Router [A] leads
to the internet. Router [C] leads to networks R, S, T, and U.
Hosts on network B can be configured with default-[A] and
as long as [A] and [C] have proper routing information via
IGP, BGP, and/or static routing including all of the more specifics,
then [A] can send back redirects to hosts on network B when they
try to reach networks {R,S,T,U}.
If you block ICMP redirects, then you won't break anything, but you
will increase the traffic load on network B and router [A] as it will
hairpin all of the traffic from those hosts to {R,S,T,U}.
Owen
Re: Verizon DSL moving to CGN
On Apr 7, 2013, at 00:31 , Mikael Abrahamsson swm...@swm.pp.se wrote: On Sun, 7 Apr 2013, Fabien Delmotte wrote: CGN is just a solution to save time, it is not a transition mechanism through IPv6 At the end (IPv6 at home) you will need at list : Dual stack or NAT64/ DNS64 CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the water without other mechanisms (464XLAT or alike). True... But... Resources deploying/maintaining all of these keep IPv4-limping along technologies are resources taken away from IPv6 deployment. My point is that people seem to scoff at CGN. There is nothing stopping anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address exhaustion), then giving dual stack for end users can be done at any time. Not really... Face it, we're running out of IPv4 addresses. For basic Internet subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a completely different problem that has little bearing on CGN or not for IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also CGN. No, it really isn't. Sufficient IPv6 deployment at the content side would actually allow the subscriber side to be IPv4 or dual-stack for existing customers with new customers receiving IPv6-only. The missing piece there is actually the set-top coversion unit for IPv4-only devices. (Ideally, a dongle which can be plugged into the back of an IPv4-only device with an IPv6-only jack on the other side. Power could be done a number of ways, including POE (with optional injector), USB, or other. I'm ok with people complaining about lack of IPv6 deployment, but I don't understand people complaining about CGN. What's the alternative? IPv6 deployment _IS_ the alternative. They are not orthogonal. Owen
Re: Verizon DSL moving to CGN
If I'm an ISP deploying a network for users today, I effectively have to provide some mechanism to allow those users to get to IPv4 only content. There is way too much stuff out there that is IPv4 only today. Yes, content providers should provide IPv6 accessbut if I'm an ISP, I can't really control that aspect. If I provide users with a service that isn't able to connect to 80% of websites (to say nothing of VPN's, corporate email services, etc, that people may need), I'm not going to have a whole lot of business. Now - I completely agree that ISP's must start deploying IPv6 natively. Legacy equipment that doesn't support IPv6 is not an acceptable excuseits just evidence of poor decision making and short-sighed purchasing decisions. CGN clearly isn't ideal and doesn't mitigate the need for native IPv6 connectivity. But right now, native IPv6 connectivity is still not a substitute for some level of IPv4 connectivity, even if its CGN'ed. Oliver - Oliver Garraux Check out my blog: blog.garraux.net Follow me on Twitter: twitter.com/olivergarraux On Sun, Apr 7, 2013 at 4:06 PM, Owen DeLong o...@delong.com wrote: On Apr 7, 2013, at 00:31 , Mikael Abrahamsson swm...@swm.pp.se wrote: On Sun, 7 Apr 2013, Fabien Delmotte wrote: CGN is just a solution to save time, it is not a transition mechanism through IPv6 At the end (IPv6 at home) you will need at list : Dual stack or NAT64/ DNS64 CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the water without other mechanisms (464XLAT or alike). True... But... Resources deploying/maintaining all of these keep IPv4-limping along technologies are resources taken away from IPv6 deployment. My point is that people seem to scoff at CGN. There is nothing stopping anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address exhaustion), then giving dual stack for end users can be done at any time. Not really... Face it, we're running out of IPv4 addresses. For basic Internet subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a completely different problem that has little bearing on CGN or not for IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also CGN. No, it really isn't. Sufficient IPv6 deployment at the content side would actually allow the subscriber side to be IPv4 or dual-stack for existing customers with new customers receiving IPv6-only. The missing piece there is actually the set-top coversion unit for IPv4-only devices. (Ideally, a dongle which can be plugged into the back of an IPv4-only device with an IPv6-only jack on the other side. Power could be done a number of ways, including POE (with optional injector), USB, or other. I'm ok with people complaining about lack of IPv6 deployment, but I don't understand people complaining about CGN. What's the alternative? IPv6 deployment _IS_ the alternative. They are not orthogonal. Owen
Re: Verizon DSL moving to CGN
On 4/6/2013 11:33 PM, Huasong Zhou 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 if you are a business customer your modem is actually a business grade NAT router. If they are using CGN(which doesn't make sense as i can pull an ipv6 addy here on dhcp) it's either a misconfiguration or something else going on.
Re: Verizon DSL moving to CGN
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
DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also CGN. 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. 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. Cheers, Rajiv Sent from my Phone On Apr 7, 2013, at 3:33 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Sun, 7 Apr 2013, Fabien Delmotte wrote: CGN is just a solution to save time, it is not a transition mechanism through IPv6 At the end (IPv6 at home) you will need at list : Dual stack or NAT64/ DNS64 CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the water without other mechanisms (464XLAT or alike). My point is that people seem to scoff at CGN. There is nothing stopping anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address exhaustion), then giving dual stack for end users can be done at any time. Face it, we're running out of IPv4 addresses. For basic Internet subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a completely different problem that has little bearing on CGN or not for IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also CGN. I'm ok with people complaining about lack of IPv6 deployment, but I don't understand people complaining about CGN. What's the alternative? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Verizon DSL moving to CGN
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. Of course, this doesn't mean that the ISP access needs to stay dual-stack, thanks to MAP, 464XLAT etc. Cheers, Rajiv Sent from my Phone On Apr 7, 2013, at 3:15 AM, Fabien Delmotte fdelmot...@mac.com wrote: CGN is just a solution to save time, it is not a transition mechanism through IPv6 At the end (IPv6 at home) you will need at list : Dual stack or NAT64/ DNS64 My 2 cents On Apr 7, 2013, at 8:42 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Sun, 7 Apr 2013, Christopher Morrow wrote: I wonder how much more painful just upgrading the dsl plant to support v6 would be vs deploying the cgn equipment and funneling users through that :( IPv6 deployment is not a short term solution to IPv4 address depletion. Would you be less upset if there was IPv6 access and CPE based DS Lite (ie your IPv4 is still CGN:ed, just in a different way)? CGN is here to stay for IPv4. The solution for long term Internet growth is IPv6. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Verizon DSL moving to CGN
In all fairness, upgrading the legacy last-mile e.g. DSL infrastructure to support native IPv6 may be too expensive to make any economic sense. Note that Vz FiOS users are not affected by this. And noting that Vz has ~5.5M FiOS HSI customers and ~3M DSL customers (per the last earning report), and noting that DSL network is not getting any new investment (in fact, customers are being moved from DSL to FiOS), the CGN usage for DSL customers isn't quite surprising. http://stopthecap.com/2012/08/20/verizon-declares-copper-dead-quietly-moving-copper-customers-to-fios-network/ Many ISPs around the world are choosing to not to invest in the DSL network the way they used to. Cheers, Rajiv Sent from my Phone On Apr 6, 2013, at 10:13 PM, Constantine A. Murenin muren...@gmail.commailto:muren...@gmail.com wrote: On 6 April 2013 18:24, cb.list6 cb.li...@gmail.commailto:cb.li...@gmail.com wrote: Interesting. http://www22.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm blockquote What is CGN - and How to opt-out The number and types of devices using the Internet have increased dramatically in recent years and, as a result, address space for these devices is being rapidly exhausted. Today’s technology for IP addresses is referred to as IPv4 (Internet Protocol version 4). The IP addresses aligned with IPv4 are expected to be depleted at some point in the near future. The next generation of IP address space is IPv6, which will enable far more addresses to be assigned than IPv4. Unfortunately, most servers and other Internet devices will not be speaking IPv6 for a while, so IPv4 will remain standard for some time to come. During this transitional period, in select areas for High Speed Internet residential customers, Verizon will be implementing Carrier Grade Network Address Translation (CGN or Carrier Grade NAT). Verizon FiOS and Verizon Business customers are not impacted at this time by the change. This transition will enable Verizon to continue serving customers with IPv4 internet addresses. CGN will not impact the access, reliability, speed, or security of Verizon’s broadband services. However, there are some applications such as online gaming, VPN access, FTP service, surveillance cameras, etc., that may not work when broadband service is provided via a CGN. For our customers utilizing these types of applications, Verizon provides the ability to opt out “of CGN. To opt out you must: Be a Residential customer with High Speed Internet Service. There is no need to “opt-out” if you are a FiOS or Business customer. Have already been transitioned to the Carrier Grade Network by Verizon. If you are a Residential High Speed Internet customer and are unable to opt-out, it is likely that you have not yet been transitioned to CGN. To opt out of CGN sign onto your My Verizon account and select Opt out of Carrier Grade Network. /blockquote I like how, according to the document, Verizon must first break your connectivity, prior to you being able to opt-out. :-) Also: select Opt out of Carrier Grade Network Smart wording. :-) Frankly, I'm surprised to see this news. I thought Verizon had better things to do that plan any kind of upgrades or changes to something that everyone thought they consider dead anyways. C.
Re: ICMP Redirect on Resolvers
On Sun, 07 Apr 2013 12:25:30 -0700, Owen DeLong said: Presumably nothing, as long as you guaranteed that your IP address, netmask, and routes actually match the reality of your network configuration. They also cover the case where there are two (or more) routers on the network and you don't want to have to configure more specific routes on all your workstations. As I said - if your config (including routes) matches your network reality. Note that the rest of your comment addresses the case where your initial config doesn't match reality... pgpTMOBD19XUS.pgp Description: PGP signature
Re: Verizon DSL moving to CGN
- Original Message - From: Rajiv Asati (rajiva) raj...@cisco.com Note that Vz FiOS users are not affected by this. And noting that Vz has ~5.5M FiOS HSI customers and ~3M DSL customers (per the last earning report), and noting that DSL network is not getting any new investment (in fact, customers are being moved from DSL to FiOS), the CGN usage for DSL customers isn't quite surprising. http://stopthecap.com/2012/08/20/verizon-declares-copper-dead-quietly-moving-copper-customers-to-fios-network/ Well, that's as may be, but since Vzn has also declared *on the record, at least 2 years ago* that they're done with FiOS -- they ain't building no more of it, if you don't have it, sorry for your luck (except maybe in KC and Austin) -- I don't know if that helps them any. 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
I can confirm CGN has not been deployed for Comcast customers. = John Jason Brzozowski Comcast Cable m) 609-377-6594 e) mailto:john_brzozow...@cable.comcast.com o) 484-962-0060 w) http://www.comcast6.net = From: Rajiv Asati (rajiva) [raj...@cisco.com] Sent: Sunday, April 07, 2013 21:11 To: Huasong Zhou Cc: Joshua Smith; nanog@nanog.org Subject: Re: Verizon DSL moving to CGN 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
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: ICMP Redirect on Resolvers
On Apr 7, 2013, at 18:47 , valdis.kletni...@vt.edu wrote: On Sun, 07 Apr 2013 12:25:30 -0700, Owen DeLong said: Presumably nothing, as long as you guaranteed that your IP address, netmask, and routes actually match the reality of your network configuration. They also cover the case where there are two (or more) routers on the network and you don't want to have to configure more specific routes on all your workstations. As I said - if your config (including routes) matches your network reality. Note that the rest of your comment addresses the case where your initial config doesn't match reality... Not true. Reality is that the default router configured on the hosts is capable of getting the packets delivered. It's not optimal, but it is reality. Owen
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
On Apr 7, 2013, at 15:43 , Oliver Garraux oli...@g.garraux.net wrote: If I'm an ISP deploying a network for users today, I effectively have to provide some mechanism to allow those users to get to IPv4 only content. There is way too much stuff out there that is IPv4 only today. Agreed... However... Yes, content providers should provide IPv6 accessbut if I'm an ISP, I can't really control that aspect. If I provide users with a service that isn't able to connect to 80% of websites (to say nothing of VPN's, corporate email services, etc, that people may need), I'm not going to have a whole lot of business. I was responding to Mikael's claim that pushing content providers to deploy IPv6 was orthogonal to the need for CGN. 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. Now - I completely agree that ISP's must start deploying IPv6 natively. Legacy equipment that doesn't support IPv6 is not an acceptable excuseits just evidence of poor decision making and short-sighed purchasing decisions. CGN clearly isn't ideal and doesn't mitigate the need for native IPv6 connectivity. But right now, native IPv6 connectivity is still not a substitute for some level of IPv4 connectivity, even if its CGN'ed. 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. Owen Oliver - Oliver Garraux Check out my blog: blog.garraux.net Follow me on Twitter: twitter.com/olivergarraux On Sun, Apr 7, 2013 at 4:06 PM, Owen DeLong o...@delong.com wrote: On Apr 7, 2013, at 00:31 , Mikael Abrahamsson swm...@swm.pp.se wrote: On Sun, 7 Apr 2013, Fabien Delmotte wrote: CGN is just a solution to save time, it is not a transition mechanism through IPv6 At the end (IPv6 at home) you will need at list : Dual stack or NAT64/ DNS64 CGN doesn't stop anyone deploying dual stack. NAT64/DNS64 is dead in the water without other mechanisms (464XLAT or alike). True... But... Resources deploying/maintaining all of these keep IPv4-limping along technologies are resources taken away from IPv6 deployment. My point is that people seem to scoff at CGN. There is nothing stopping anyone putting in CGN for IPv4 (that has to be done to handle IPv4 address exhaustion), then giving dual stack for end users can be done at any time. Not really... Face it, we're running out of IPv4 addresses. For basic Internet subscriptions the IPv4 connectivity is going to be behind CGN. IPv6 is a completely different problem that has little bearing on CGN or not for IPv4. DS-Lite is also CGN, it just happens to be done over IPv6 access. MAP is also CGN. No, it really isn't. Sufficient IPv6 deployment at the content side would actually allow the subscriber side to be IPv4 or dual-stack for existing customers with new customers receiving IPv6-only. The missing piece there is actually the set-top coversion unit for IPv4-only devices. (Ideally, a dongle which can be plugged into the back of an IPv4-only device with an IPv6-only jack on the other side. Power could be done a number of ways, including POE (with optional injector), USB, or other. I'm ok with people complaining about lack of IPv6 deployment, but I don't understand people complaining about CGN. What's the alternative? IPv6 deployment _IS_ the alternative. They are not orthogonal. Owen
