Re: 97.128.0.0/9 allocation to verizon wireless
I have trouble understanding why an ARIN record for a network regularly receiving new, out-sized IPv4 allocations on the order of millions of OrgName:Cellco Partnership DBA Verizon Wireless CIDR: 97.128.0.0/9 Comment:Verizon Wireless currently has 44.3 Million Comment:subscribers with 2.097 Million IP addresses allocated. RegDate:2008-04-14 If they have immediately allocated 2.097 million out of 8.388 million, then they have satisfied the 25% immediate utilization requirement. In fact, 2.097 million is exactly how many they would need immediate use for in order to justify an allocation of 8 million IPs according to ARIN policy. I expect the 2.097 million figure applies only to this particular range, this comment in whois does not indicate that Verizon has _only_ assigned that many across all its various ranges; I would fully expect they have massively more IPs in use. I would expect ARIN would have followed policy, and so Verizon had to show to ARIN their well-founded projection that within one year, at least 50% of the new assignment would be allocated. And also that they met the additional requirements for ISPs; 80% utilization over all previous allocations, and also 80% of their most recent allocation. -- -Jimmy
Re: 97.128.0.0/9 allocation to verizon wireless
On 2/8/09 3:24 AM, Jeff S Wheeler wrote: Sure, smart phones are becoming more popular. It's reasonable to assume that virtually all cell phones will eventually have an IP address almost all the time. The numbers I keep seeing for so-called smartphones in the press for U.S. and Europe are 49% and 50% within two years, respectively. Here's an article you might find interesting about the U.S. domestic market, and it may help you calculate what sort of growth rate we can expect in the future, when combined with both of the above numbers. Put another way, the news is bad, but there is a cap on growth. http://albuquerque.bizjournals.com/dallas/stories/2008/09/29/story10.html Eliot
Re: 97.128.0.0/9 allocation to verizon wireless
Exactly. On Sun, Feb 8, 2009 at 10:04 AM, Joel Jaeggli joe...@bogus.com wrote: Eliot Lear wrote: On 2/8/09 3:24 AM, Jeff S Wheeler wrote: Sure, smart phones are becoming more popular. It's reasonable to assume that virtually all cell phones will eventually have an IP address almost all the time. The numbers I keep seeing for so-called smartphones in the press for U.S. and Europe are 49% and 50% within two years, respectively. Here's an article you might find interesting about the U.S. domestic market, and it may help you calculate what sort of growth rate we can expect in the future, when combined with both of the above numbers. Put another way, the news is bad, but there is a cap on growth. We live in rather sad times if, subscriber, arpu and internet usage growth is considered bad news. http://albuquerque.bizjournals.com/dallas/stories/2008/09/29/story10.html Eliot
Re: 97.128.0.0/9 allocation to verizon wireless
I have no personal knowledge of this situation, so this is wild speculation. http://news.cnet.com/verizon-completes-alltel-purchase/ Verizon Wireless is going to be soon selling operations in 105 markets. It may well be that the IP addresses for those markets will be transfered to the new company as well, and you'll see some of these blocks leave their name soon. It could also be that AllTel had a much lower percentage of subscribers using data, and Verizon is fixing to change that soon. With the merger complete Verizon Wireless will have 83.7 million subscribers (per the article). I see 27,371,520 IP's in all their advertised blocks now, add in the 8,388,608 they just got, for a total of 35,760,128. If we assume across all blocks they can get 80% USAGE efficiency (which would surprise me) that's enough IP's to feed data to 28,608,102 subs. That would mean they can serve about 34% of their customers with data. Lastly, you've assumed that only a smart phone (not that the term is well defined) needs an IP address. I believe this is wrong. There are plenty of simpler phones (e.g. not a PDA, touch screen, read your e-mail thing) that can use cellular data to WEP browse, or to fetch things like ring tones. They use an IP on the network. By the same math they have 55.1 million (83.7 million subs - 28.6 they can serve now) they can't serve data to yet, and using the same 80% effiency that will take another 68.9 million addresses to do that. A /6 has 67.1 million addresses, so I suspect you'll see over time another /6, or two /7's, or four /8's, or eight /9's... Which leaves us with two take aways: 1) The comment is weird. 2) If one company is likely to need four more /8's, and there are now 32 in the free pool man is IPv4 in trouble. At this point it would only take eight companies the size of verizon wireless to exhaust the free pool WORLDWIDE. No matter how much effort we put into reclaiming IPv4 space there's just no way to keep up with new demand. Is your network IPv6 enabled yet? -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpWqMD1lgDsF.pgp Description: PGP signature
Re: 97.128.0.0/9 allocation to verizon wireless
Leo Bicknell: Lastly, you've assumed that only a smart phone (not that the term is well defined) needs an IP address. I believe this is wrong. There are plenty of simpler phones (e.g. not a PDA, touch screen, read your e-mail thing) that can use cellular data to WEP browse, or to fetch things like ring tones. They use an IP on the network. Alternatively, Verizon is planning to build an all-IP NGN architecture in the near future, or is at least providing for the possibility of building one. Mobilkom Austria, for example, has done a deal with Fring to put their SIP VoIP client on handsets and serve their voice traffic over IP. In that case, you'd need IP addresses for all the people who use VOICE. You can do ringtones and the like through USSD...but there's no escape from voice.
Re: 97.128.0.0/9 allocation to verizon wireless
2) If one company is likely to need four more /8's, and there are now 32 in the free pool man is IPv4 in trouble. It's going to happen soon enough anyway. At this point it would only take eight companies the size of verizon wireless to exhaust the free pool WORLDWIDE. No matter how much effort we put into reclaiming IPv4 space there's just no way to keep up with new demand. If they were allowed to. At some point I hope (I've heard the RIRs are making plans) they'll be told no, you can't roll out something that big as v4, that's enough infrastructure you can afford to build it as v6, the rest of the v4 is now only for smaller necessary v4 use. What is necessary v4 and the v6 only threshold can now be argued over while everyone else gets on with building v6 or big v4 NATs brandon
Re: Seeking FIOS tech support with two (or more) brain cells
A big thank-you to everyone who replied, called, sent kind words and shared frustration. Clearly I'm not alone here (even had frustration shared by people who actually work in a different business unit of Verizon), and it would be nice if the folks at VZ would take some steps to fix these apparently-endemic problems but so far no joy. Eventually I got called back by someone who, after listening to what I want to do, said I know... we can turn off the MOCA and turn on the Ethernet right on your ONT, bypassing the firewall completely. Would that accomplish what you want to do? I said yes, and we're now sailing happily along. No word yet on whether this burns our ability to get FIOS TV or not. Also, sadly, no way to repeat it other than the old escalate, escalate, escalate dance. I'm still not clear on how this was supposed to be a business service if you weren't intended to hang your own CPE on it. -r
RE: L3: Google from DC via the Netherlands?
After a few emails traded with David Ulevitch from OpenDNS, it is clear to me that they do NOT suffer from this issue, and have a work-around. My apologies to David and to OpenDNS for lumping them in and not doing better due dilligence when researching this issue. On Sat, 7 Feb 2009, TJ wrote: IMHO, off the top of my head, on a weekend where I haven't had enough coffee yet: 3. Anycasted DNS Providers? Not sure how they could fix it, other than flag certain domains as special, and do something special for them, but man that smells like a hack. Anycast is a good thing, but when geo-location style concerns are factored in maybe they should have region-based anycast addresses. Anycast is extremely useful for fault tolerance, agreed. But what I personally didn't consider, and I don't think other people consider, when they chose to use an alternative DNS caching resolution providers is what might break or not operate as expected. Having traded a few private emails from people smarter than I at Google and OpenDNS, I understand the issue much better than when I first posted. Thank you to you both. Here's a theoretical solution to this problem that I'd like to open for discussion. In each location where a provider hosts their anycasted service, there is likely a local, non-anycasted IP address for each server. When receiving a DNS request that is not in the local cache, or has expired, make the new request on that local IP address interface, rather than on the anycasted IP address interface. In those cases, GSLB records would likely return a more accurate set of results for clients making DNS requests of it, and when those records were requested from the anycasted DNS resolving service, the cached records would more likely be closer from a network standpoint to the actual service. Obviously there are some issues: * need to patch BIND or PowerDNS to use a different interface for making new requests * possibility of the responding anycasted DNS server being close to server farm A, while being far away from DNS record requestor B I'm curious to find out if others on the list know what other companies are using GSLB, and what the actual impact of anycasted DNS caching nameservers has on GSLB records. If enough people are using anycasted DNS resolution services, implementing a fix like this would reduce network traffic. By how much, I don't know. Beckman --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.com/ ---
Re: L3: Google from DC via the Netherlands?
In message alpine.bsf.2.00.0902081439461.72...@nog.angryox.com, Peter Beckman writes: After a few emails traded with David Ulevitch from OpenDNS, it is clear to me that they do NOT suffer from this issue, and have a work-around. My apologies to David and to OpenDNS for lumping them in and not doing better due dilligence when researching this issue. On Sat, 7 Feb 2009, TJ wrote: IMHO, off the top of my head, on a weekend where I haven't had enough coffe e yet: 3. Anycasted DNS Providers? Not sure how they could fix it, other than flag certain domains as special, and do something special for them, but man that smells like a hack. Anycast is a good thing, but when geo-location style concerns are factored in maybe they should have region-based anycast addresses. Anycast is extremely useful for fault tolerance, agreed. But what I personally didn't consider, and I don't think other people consider, when they chose to use an alternative DNS caching resolution providers is what might break or not operate as expected. Having traded a few private emails from people smarter than I at Google and OpenDNS, I understand the issue much better than when I first posted. Thank you to you both. Here's a theoretical solution to this problem that I'd like to open for discussion. In each location where a provider hosts their anycasted service, there is likely a local, non-anycasted IP address for each server. When receiving a DNS request that is not in the local cache, or has expired, make the new request on that local IP address interface, rather than on the anycasted IP address interface. In those cases, GSLB records would likely return a more accurate set of results for clients making DNS requests of it, and when those records were requested from the anycasted DNS resolving service, the cached records would more likely be closer from a network standpoint to the actual service. Obviously there are some issues: * need to patch BIND or PowerDNS to use a different interface for making new requests query-source ; * possibility of the responding anycasted DNS server being close to server farm A, while being far away from DNS record requestor B I'm curious to find out if others on the list know what other companies are using GSLB, and what the actual impact of anycasted DNS caching nameservers has on GSLB records. If enough people are using anycasted DNS resolution services, implementing a fix like this would reduce network traffic. By how much, I don't know. Beckman --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.com/ --- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: 97.128.0.0/9 allocation to verizon wireless
On Sun, 08 Feb 2009 22:45:51 +0100 Eliot Lear l...@cisco.com wrote: On 2/8/09 5:32 PM, Leo Bicknell wrote: Lastly, you've assumed that only a smart phone (not that the term is well defined) needs an IP address. I believe this is wrong. There are plenty of simpler phones (e.g. not a PDA, touch screen, read your e-mail thing) that can use cellular data to WEP browse, or to fetch things like ring tones. They use an IP on the network. The term is ill defined, but the general connotation is that they will be supplanting dumb phones. So say what you will,phones with IP addresses is likely to increase as a percentage of the installed base. The only thing offsetting that is the indication that the U.S. is saturating on total # of cell phones, which is what that article says. Of course, my iPhone is currently showing an IP address in 10/8, and though my EVDO card shows a global address in 70.198/16, I can't ssh to it -- a TCP traceroute appears to be blocked at the border of Verizon Wireless' network. But hey, at least I can ping it. (Confirmed by tcpdump on my laptop: the pings are not being spoofed by a border router.) --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: L3: Google from DC via the Netherlands?
Here's a theoretical solution to this problem that I'd like to open for discussion. In each location where a provider hosts their anycasted service, there is likely a local, non-anycasted IP address for each server. There should be, yes. When receiving a DNS request that is not in the local cache, or has expired, make the new request on that local IP address interface, rather than on the anycasted IP address interface. Yes. You probably have to do this in any case. Think about it. If you have anycasted recursers in IAD, SJC, AMS, and HKG, and you're asking for an answer hosted on a nameserver near IAD, and the query goes from the anycast address to the near-IAD auth nameserver, then the response will probably wind up at IAD, even if it was the HKG server asking. That will not enable the HKG server to answer you. You can probably hack your way around that issue by creative use of VPNs and port assignments, but that's just a really poor-sounding solution. Using the local IP address makes the right thing just magically happen. I'm curious to find out if others on the list know what other companies are using GSLB, and what the actual impact of anycasted DNS caching nameservers has on GSLB records. If enough people are using anycasted DNS resolution services, implementing a fix like this would reduce network traffic. By how much, I don't know. The real problem is that if you're using an anycasted service, there is a good chance that the recurser you're using is much further away from you topologically than if you were just using a local recurser. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
RE: IPv6 delivery model to end customers
I didn't know where to jump in in the current discussion and what I wanted to discuss was quite general, so I thought I'd create a new thread instead. And the right move, IMHO! (FWIW) So, anyone saying IPv6 is ready for prime-time whereever IPv4 is used, has a very simplified view of the world. Yes, IPv6 works in the classic routed network model where everything is statically set up (often manually), for example with an ISP run CPE and static/dynamic routing and a fixed /48 issued for that customer and SWIPed. Then it's easy to delegate reverse-DNS etc to the customer DNS. We would need to differentiate between the protocol being ready, and the vendors' support of the protocol here. In other words, the ivory tower work is done - now it is up to the real world. Oh, and yes, in that enterprise deployment scenario we are almost ready! SNIP My ideal model would be to replace the above mentioned L2 device with a small and simple L3 device (L3 switch) with very small TCAM (TCAM size 6-8 times port number should be enough), where this device uses link-local with the CPEs (would require all customers to actually have a router at home), hands out prefixes via DHCPv6-PD, inserts route towards customer link-local address, provisions anti-spoofing ACLs on that port, logs what prefix was given out to each port at what time, and off we go. (Rationale for link- local only is to have only customer devices in Customer IP space and only ISP infrastructure in that IP-space. This is equivalent to ip unnumbered in IPv4 in my view.) I have pitched this idea in the IETF v6ops list and it's now included in a draft that lists different models of IPv6 delivery. As far as I know, this IPv6 L3 device doesn't exist (in the pricerange needed for massive residential roll-out anyhow). While that sounds functional/useful, I would first ask - to the residential-focused ISPs - how they currently plan (or how are they moving towards) delivering IPv6 to their clients? So, in the meantime, to get IPv6 to the end customers I see two ways (because they need to fit into the IPv4 security model mentioned above). We have either 6to4 tunneling (Cisco 7600 does this very well and code for Linux CPEs exist already), or we try to fit IPv6 into the IPv4 security model. Current recommendation from the swedish city networks association (they consists mostly of entities running LANs to residential, I believe there are approx 400-500k ports of that in Sweden at this time) is that if you don't know if your network is secure against IPv6, block it at the ethertype level (I'll come back to the security risks later). 6to4 works just fine, assuming you and your customers are OK with tunneling and relays ... up until there are no more public IPs. Then you are talking about A+P + 6to4 or somesuch. *EVEN MORE FUN* SNIP So, what is the security problem with IPv6 in an IPv4 network? Well, imagine an IPv4 network where security is done via ARP inspection, DHCP snooping and L3 ACLs. Now, insert rogue customer who announces itself via RA/DHCPv6 and says it's also DNS. Vista machines will get itself an IPv6 address via RA, ask for DNS-server via DHCPv6, so if the rogue customer can do some NAT-PT like functionality, they are now man in the middle for all the IPv4 traffic (because between the customers it's IPv6 and the L2 device doesn't know anything about that). I don't know if this has actually been done, but I see no theoretical problem with it, if someone can come up with something, please do tell. RA Guard; learn it, live it, love it. At some point, maybe SEND/CGA as well ... but that isn't a ready today thing. So, my view on IPv6 is that I would love to roll it out to all residential customers, but unfortunately all the development done for IPv4 security has gone unnoticed by the people developing IPv6 and now it's behind and needs to catch up, or pitch a different model and then get vendors to develop products that do this. I think that is a bit harsh - the work hasn't gone unnoticed. Rather, it has not been high enough on the list of priorities and is therefore, yes, lagging. In the mean time, we do (and I encourage everybody else to do the same) support 6to4 and Teredo, plus we do IPv6 native in the core and peering where possible plus we give IPv6 to customers where we're able to securely (mostly transit customers and corporate customers with IPv6 capable CPEs). AMEN!
RE: v6 DSL / Cable modems
I suppose you can individually configure every host to get itself temporary addresses from RA announcements. This isn't usually a good default configuration, but OS implementation already seems to be inconsistent on the default configuration here. So we're back to the IPv4 dark ages where you have to walk around to all the devices to effect changes in policy (beyond prefix field contents). I'm not sure, but you seem to be implying that you need to configure hosts to tell them to use RA or DHCPv6 to get addresses. My apologies if this is not your intention. RA messages are always going to be sent by routers and received by hosts, even if DHCPv6 is being used for address assignment. This does not seem to be generally true: - For the routers I am most familiar with (Juniper M/MX), you need to explicitly turn on router advertisement to make the router perform this. I.e. it is perfectly possible to have an interface with an IPv6 address which does *not* send RAs. Yes, vendors differ ... for Ciso/IOS - broadcast capable, multi-access interfaces (a la Ethernet) will automatically send RAs ones a /64 IPv6 address is configured. Or once you explicitly tell it to advertise one. - For the operating system I am most familiar with (FreeBSD), RAs are *not* accepted by default if the interface in question is configured with a static IPv6 address. I don't believe that is the general behavior, and specifically - for Win* a static being configured does not prevent autoconfiguration. And this is the correct behavior - to allow for cases where multiple prefixes are correct/expected, and only one is static. Both of these choices seem perfectly reasonable to me. I slightly disagree on the latter; autoconfiguration in the presence of RAs (including a (or several) prefix options) should be the default. ((... and now begins (continues, really) the pseudo-religious debate between the autoconfiguration people and the DHCPv6 people ...)) /TJ
Re: 97.128.0.0/9 allocation to verizon wireless
On Sat, Feb 7, 2009 at 8:06 PM, Jeffrey Lyon jeffrey.l...@blacklotus.net wrote: Whatever happened to NAT? Jeff NAT? why isn't Verizon 'It's the Network' Wireless using IPv6? speaking-from-assthere should be a FOIA-like method to see large allocation justifications/ass
Re: 97.128.0.0/9 allocation to verizon wireless
On Sun, 2009-02-08 at 14:37 -0800, Aaron Glenn wrote: NAT? why isn't Verizon 'It's the Network' Wireless using IPv6? speaking-from-assthere should be a FOIA-like method to see large allocation justifications/ass Realistically, I suppose Verizon Wireless is big enough to dictate to the manufacturers of handsets and infrastructure, you must support IPv6 by X date or we will no longer buy / sell your product. I wonder if any wireless carriers are doing this today? What services require an IP, whether they can be supplied via NAT, how soon smart phone adoption will bring IP to every handset ... all these are good and valid points. However, they all distract from the glaring and obvious reality that there is no current explanation for Verizon Wireless needing 27M IPs. Does ARIN lack sufficient resources to vet jumbo requests? Did Verizon Wireless benefit from favoritism? Is Barack Obama concerned that his blackberry will not function if Verizon one day runs out of v4 addresses for its customers? - j
RE: 97.128.0.0/9 allocation to verizon wireless
Does ARIN lack sufficient resources to vet jumbo requests? I am fairly confident ARIN followed their policies. The existing policies allow anyone (including Verizon) to make a request for (and receive) a /9 with appropriate justification. If you do not like the policies, please participate in the ARIN policy process and work to change them. Mailing lists: arin-p...@arin.net Open to the general public. Provides a forum to raise and discuss policy-related ideas and issues surrounding existing and proposed ARIN policies. The PPML list is an intrinsic part of ARIN's Policy Development Process (PDP), which details how proposed policies are handled. http://www.arin.net/mailing_lists/index.html
Re: 97.128.0.0/9 allocation to verizon wireless
In message 1234128761.17985.352.ca...@guardian.inconcepts.net, Jeff S Wheeler writes: On Sun, 2009-02-08 at 14:37 -0800, Aaron Glenn wrote: NAT? why isn't Verizon 'It's the Network' Wireless using IPv6? speaking-from-assthere should be a FOIA-like method to see large allocation justifications/ass Realistically, I suppose Verizon Wireless is big enough to dictate to the manufacturers of handsets and infrastructure, you must support IPv6 by X date or we will no longer buy / sell your product. I wonder if any wireless carriers are doing this today? What services require an IP, whether they can be supplied via NAT, how soon smart phone adoption will bring IP to every handset ... all these are good and valid points. However, they all distract from the glaring and obvious reality that there is no current explanation for Verizon Wireless needing 27M IPs. Well it's a 8M allocation for current population of 2M with a 25M more potential handsets that will be upgraded soon. This looks to be consistent with how ARIN hands out other blocks of address space. Say on average that you replace a cell phone every three years. In 6 months there will be ~4M more addresses needed. I don't see any reason to complain based on those numbers. It's just a extremely high growth period due to technology change over bring in new functionality. Mark Does ARIN lack sufficient resources to vet jumbo requests? Did Verizon Wireless benefit from favoritism? Is Barack Obama concerned that his blackberry will not function if Verizon one day runs out of v4 addresses for its customers? - j -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: 97.128.0.0/9 allocation to verizon wireless
On Sun, Feb 8, 2009 at 4:07 PM, Mark Andrews mark_andr...@isc.org wrote:
I don't see any reason to complain based on those numbers.
It's just a extremely high growth period due to technology
change over bring in new functionality.
so if they don't deploy IPv6 then ('extremely high growth period'),
when will they? I don't presume to speak for everyone who immediately
felt that tinge of surprise at reading of a /9 being allocated, but
the blame is being laid on vzw not doing something other than 'can we
have a /9 please?' --not ARIN and/or it's policies (another mailing
list, duly noted)
RE: 97.128.0.0/9 allocation to verizon wireless
This discussion about smartphones and the like was presuming that those devices all received public IPs -- my experience has been more often than not that they get RFC 1918 addresses. Frank -Original Message- From: Steven M. Bellovin [mailto:s...@cs.columbia.edu] Sent: Sunday, February 08, 2009 3:58 PM To: Eliot Lear Cc: nanog@nanog.org Subject: Re: 97.128.0.0/9 allocation to verizon wireless On Sun, 08 Feb 2009 22:45:51 +0100 Eliot Lear l...@cisco.com wrote: On 2/8/09 5:32 PM, Leo Bicknell wrote: Lastly, you've assumed that only a smart phone (not that the term is well defined) needs an IP address. I believe this is wrong. There are plenty of simpler phones (e.g. not a PDA, touch screen, read your e-mail thing) that can use cellular data to WEP browse, or to fetch things like ring tones. They use an IP on the network. The term is ill defined, but the general connotation is that they will be supplanting dumb phones. So say what you will,phones with IP addresses is likely to increase as a percentage of the installed base. The only thing offsetting that is the indication that the U.S. is saturating on total # of cell phones, which is what that article says. Of course, my iPhone is currently showing an IP address in 10/8, and though my EVDO card shows a global address in 70.198/16, I can't ssh to it -- a TCP traceroute appears to be blocked at the border of Verizon Wireless' network. But hey, at least I can ping it. (Confirmed by tcpdump on my laptop: the pings are not being spoofed by a border router.) --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: 97.128.0.0/9 allocation to verizon wireless
On Feb 8, 2009, at 7:37 PM, Aaron Glenn wrote:
so if they don't deploy IPv6 then ('extremely high growth period'),
when will they?
Hint: how many of the (say) Alexa top 1000 websites are IPv6 enabled?
Regards,
-drc
RE: 97.128.0.0/9 allocation to verizon wireless
For better or worse, Verizon hands out globally routable addresses for smartphones. (Certainly, the one I've got has one.) They seem to come from the same pool as data card links. Note that I suspect that there's a nontrivial number of folk that are used to using some not quite really NAT friendly protocols like IPsec on their (targeted-for-business primarily not iPhone smartphones). (Yeah, there's IPsec NAT-T, which I've seen fall flat on its face countless times.) Breaking that sort of connectivity is likely to be hard to swallow for some nontrivial portion of some of their customers. - S -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: Sunday, February 08, 2009 10:48 PM To: nanog@nanog.org Subject: RE: 97.128.0.0/9 allocation to verizon wireless This discussion about smartphones and the like was presuming that those devices all received public IPs -- my experience has been more often than not that they get RFC 1918 addresses. Frank -Original Message- From: Steven M. Bellovin [mailto:s...@cs.columbia.edu] Sent: Sunday, February 08, 2009 3:58 PM To: Eliot Lear Cc: nanog@nanog.org Subject: Re: 97.128.0.0/9 allocation to verizon wireless On Sun, 08 Feb 2009 22:45:51 +0100 Eliot Lear l...@cisco.com wrote: On 2/8/09 5:32 PM, Leo Bicknell wrote: Lastly, you've assumed that only a smart phone (not that the term is well defined) needs an IP address. I believe this is wrong. There are plenty of simpler phones (e.g. not a PDA, touch screen, read your e-mail thing) that can use cellular data to WEP browse, or to fetch things like ring tones. They use an IP on the network. The term is ill defined, but the general connotation is that they will be supplanting dumb phones. So say what you will,phones with IP addresses is likely to increase as a percentage of the installed base. The only thing offsetting that is the indication that the U.S. is saturating on total # of cell phones, which is what that article says. Of course, my iPhone is currently showing an IP address in 10/8, and though my EVDO card shows a global address in 70.198/16, I can't ssh to it -- a TCP traceroute appears to be blocked at the border of Verizon Wireless' network. But hey, at least I can ping it. (Confirmed by tcpdump on my laptop: the pings are not being spoofed by a border router.) --Steve Bellovin, http://www.cs.columbia.edu/~smb
RE: 97.128.0.0/9 allocation to verizon wireless
I think that you've got a bit of a logic fault here. You seem to be assuming
that because you can't find any external any sign of Verizon preparing for
IPv6, that they're definitely not doing so.
Maybe they are, maybe they aren't (your -guess- is as good as mine), but that
process is not necessarily going to be broadcast to the entire world.
Especially after the earlier thread via customer IPv6 rollouts by ISPs, I think
it should be fairly evident that there can be nontrivial backend plumbing
work needed to get things IPv6 ready, not all of which is necessarily going to
be inherently customer-visible for all stages of progress.
- S
-Original Message-
From: Aaron Glenn [mailto:aaron.gl...@gmail.com]
Sent: Sunday, February 08, 2009 10:37 PM
To: nanog@nanog.org
Subject: Re: 97.128.0.0/9 allocation to verizon wireless
On Sun, Feb 8, 2009 at 4:07 PM, Mark Andrews mark_andr...@isc.org wrote:
I don't see any reason to complain based on those numbers.
It's just a extremely high growth period due to technology
change over bring in new functionality.
so if they don't deploy IPv6 then ('extremely high growth period'),
when will they? I don't presume to speak for everyone who immediately
felt that tinge of surprise at reading of a /9 being allocated, but
the blame is being laid on vzw not doing something other than 'can we
have a /9 please?' --not ARIN and/or it's policies (another mailing
list, duly noted)
Re: 97.128.0.0/9 allocation to verizon wireless
On Sun, Feb 8, 2009 at 5:37 PM, Aaron Glenn aaron.gl...@gmail.com wrote: NAT? why isn't Verizon 'It's the Network' Wireless using IPv6? speaking-from-assthere should be a FOIA-like method to see large allocation justifications/ass Probably because Verizon Business isn't using it, unless you count a couple of lab GRE tunnels. Drive Slow, Paul Wall
Re: 97.128.0.0/9 allocation to verizon wireless
On Sun, Feb 8, 2009 at 4:32 PM, Jeff S Wheeler j...@inconcepts.biz wrote: What services require an IP, whether they can be supplied via NAT, how soon smart phone adoption will bring IP to every handset ... all these are good and valid points. However, they all distract from the glaring and obvious reality that there is no current explanation for Verizon Wireless needing 27M IPs. 27 million IP addresses for 45 million customers with addressable devices sounds well within ARIN's justification guidelines. Just because most of your customers are trying to pull the wool over ARIN's eyes doesn't mean Verizon is too. :) Drive Slow, Paul Wall
Re: 97.128.0.0/9 allocation to verizon wireless
On Mon, Feb 9, 2009 at 1:08 AM, Paul Wall pauldotw...@gmail.com wrote: On Sun, Feb 8, 2009 at 5:37 PM, Aaron Glenn aaron.gl...@gmail.com wrote: NAT? why isn't Verizon 'It's the Network' Wireless using IPv6? speaking-from-assthere should be a FOIA-like method to see large allocation justifications/ass Probably because Verizon Business isn't using it, unless you count a couple of lab GRE tunnels. so... actually... if you ask for v6 apparently vzb's deployment is still moving along and is accessible for customers. FiOS/DSL though is not :( -Chris
Re: 97.128.0.0/9 allocation to verizon wireless
David Conrad wrote:
On Feb 8, 2009, at 7:37 PM, Aaron Glenn wrote:
so if they don't deploy IPv6 then ('extremely high growth period'),
when will they?
Hint: how many of the (say) Alexa top 1000 websites are IPv6 enabled?
haha, I went insane for a moment and though you said Freenix top 1000,
and so I just checked that. Here is the answer to the question you
didn't ask:
Top 1000 Usenet Servers in the World
list here: http://news.anthologeek.net/top1000.current.txt
details here: http://news.anthologeek.net
1000 usenet server names
913 are potentially valid hostnames (in usenet news a server name does
necessarily correspond directly to a hostname)
722 have ipv4 address records (A)
67 have ipv6 address records ()
9.2% of the top 1000 usenet servers have added support for ipv6
I'm sure there are more this took exactly 183 seconds of work. ;)
Here they are:
feeder.erje.net 2001:470:992a::3e19:561
feeder4.cambrium.nl 2a02:58:3:119::4:1
news.dal.ca 2001:410:a010:1:214:5eff:fe0a:4a4e
news.nonexiste.net 2002:6009:93d5::1
nrc-news.nrc.ca 2001:410:9000:2::2
news.z74.net 2001:610:637:4::211
news.kjsl.com 2001:1868:204::104
npeer.de.kpn-eurorings.net 2001:680:0:26::2
feeder6.cambrium.nl 2a02:58:3:119::6:1
feeder3.cambrium.nl 2a02:58:3:119::3:1
news.belnet.be 2001:6a8:3c80::38
feeder2.cambrium.nl 2a02:58:3:119::2:1
feeder5.cambrium.nl 2a02:58:3:119::5:1
syros.belnet.be 2001:6a8:3c80::17
vlad-tepes.bofh.it 2001:1418:13:1::5
news.stack.nl 2001:610:1108:5011:230:48ff:fe12:2794
ikarus.belnet.be 2001:6a8:3c80::38
news.space.net 2001:608::1000:7
feed.news.tnib.de 2001:1b18:f:4::4
newsfeed.velia.net 2a01:7a0:3::254
news.isoc.lu 2001:a18:0:405:0:a0:456:1
ikaria.belnet.be 2001:6a8:3c80::39
newsfeed.teleport-iabg.de 2001:1b10:100::119:1
news.tnib.de 2001:1b18:f:4::2
kanaga.switch.ch 2001:620:0:8::119:2
erode.bofh.it 2001:1418:13:1::3
irazu.switch.ch 2001:620:0:8::119:3
bofh.it 2001:1418:13::42
newsfeed.atman.pl 2001:1a68:0:4::2
news.mb-net.net 2a01:198:292:0:210:dcff:fe67:6b03
news.gnuher.de 2a01:198:293::2
switch.ch 2001:620:0:1b::b
news.k-dsl.de 2a02:7a0:1::5
news.task.gda.pl 2001:4070:1::fafe
news1.tnib.de 2001:1b18:f:4::2
aspen.stu.neva.ru 2001:b08:2:100::96
novso.com 2001:1668:2102:4::4
citadel.nobulus.com 2001:6f8:892:6ff::11:133
feeder.news.heanet.ie 2001:770:18:2::c101:db29
news-zh.switch.ch 2001:620:0:3::119:1
news.szn.dk 2001:1448:89::10:d85d
news.litech.org 2001:440:fff9:100:202:b3ff:fea4:a44e
news.weisnix.org 2001:6f8:892:6ff:213:8fff:febb:bec3
news.panservice.it 2001:40d0:0:4000::e
nntp.eutelia.it 2001:750:2:3::20
bolzen.all.de 2001:bf0::60
newsfeed.esat.net 2001:7c8:3:1::3
news.snarked.org 2607:f350:1::1:4
feed1.news.be.easynet.net 2001:6f8:200:2::5:46
aotearoa.belnet.be 2001:6a8:3c80::58
news.babsi.de 2a01:198:292:0:230:48ff:fe51:a68c
news.muc.de 2001:608:1000::2
newsfeed.carnet.hr 2001:b68:e160::3
news.nask.pl 2001:a10:1:::3:c9a2
news.linuxfan.it 2001:4c90:2::6
texta.sil.at 2001:858:2:1::2
news.stupi.se 2001:440:1880:5::10
news.supermedia.pl 2001:4c30:0:3::12
news.trigofacile.com 2001:41d0:1:6d44::1
nuzba.szn.dk 2001:6f8:1232::263:8546
geiz-ist-geil.priv.at 2001:858:666:f001::57
newsfeed.sunet.se 2001:6b0:7:88::101
news.pimp.lart.info 2001:6f8:9ed::1
glou.fr.eu.org 2001:838:30b::1
news.germany.com 2001:4068:101:119:1::77
feeder.z74.net 2001:610:637:4::211
news.nask.org.pl 2001:a10:1:::3:c9a2
Mike.
--
+ H U R R I C A N E - E L E C T R I C +
| Mike LeberWholesale IPv4 and IPv6 Transit 510 580 4100 |
| Hurricane Electric AS6939 |
| mle...@he.net Internet Backbone Colocation http://he.net |
+-+
Packet Loss between Qwest and Global Crossing
This post to the NANOG list in the hope that an interested engineer from either Qwest or GBLX will act on the problem I have observed. I've identified a packet loss problem (10-15%) between Qwest and Global Crossing. From one end (HP), the partial traceroute is: traceroute to 68.85.190.221 (68.85.190.221), 30 hops max, 40 byte packets 1 lpagwb01-vlan151-phy.hpl.hp.com (192.6.19.2) 0.622 ms 0.378 ms 0.315 ms 2 * * * 3 * * * 4 65.115.64.25 (65.115.64.25)1.380 ms 1.297 ms 1.233 ms 5 205.171.14.150 (205.171.14.150)1.377 ms 1.385 ms 1.277 ms 6 67.14.34.14 (67.14.34.14) 1.955 ms 2.046 ms 1.962 ms 7 205.171.233.18 (205.171.233.18)2.204 ms 2.204 ms 2.076 ms 8 63.146.26.42 (63.146.26.42)5.937 ms 4.253 ms 4.574 ms 9 * COMCAST-IP-SERVICES-LLC.TenGigabitEthernet1-3.ar2.snv2.gblx.net (64.211.1.214)21.942 ms 21.670 ms There's no packet loss until the `gblx.net' (64.211.1.214) is pinged. Coming from the other end (Comcast), the partial traceroute is: Tracing route to gundega.hpl.hp.com [192.6.19.190] over a maximum of 30 hops: 1* * * Request timed out. 29 ms7 ms7 ms 68.85.190.221 38 ms6 ms6 ms 68.87.226.66 47 ms6 ms7 ms te-9-1-ur06.sanjose.ca.sfba.comcast.net [68.87.192.54] 59 ms9 ms 11 ms te-0-3-0-4-ar01.oakland.ca.sfba.comcast.net [68.87.226.229] 6 11 ms 11 ms 11 ms pos-0-4-0-0-cr01.sacramento.ca.ibone.comcast.net [68.86.90.141] 7 13 ms 12 ms 13 ms pos-0-8-0-0-cr01.sanjose.ca.ibone.comcast.net [68.86.85.78] 8 14 ms 12 ms 12 ms TenGigabitEthernet3-1.ar1.snv2.gblx.net [64.214.174.109] 9 41 ms* 38 ms sjp-brdr-02.inet.qwest.net [63.146.26.41] Pinging from this direction, there no packet loss until the first Qwest router (63.146.26.41) is pinged. So it seems clear that the problem is between Qwest and Global Crossing. -- Andris
Re: Private use of non-RFC1918 IP space
valdis.kletni...@vt.edu wrote: On Tue, 03 Feb 2009 11:25:40 +0900, Randy Bush said: snip Not quite.. 2^96 = 79228162514264337593543950336 2^128-2^32 = 340282366920938463463374607427473244160 not quite. let's posit 42 devices on the average lan segment (ymmv). 42*(2^64) = 774763251095801167872 Let's face it - they're going to have to come up with much more creative $200/hour chucklehead consultants to burn through that much anytime soon. snip Anybody feel like starting a pool for when we'll see a posting to NANOG about somebody who's managed to burn through a /32? two of them will separately just assign fc00::/7 to a network instead of following the instructions.
Automatic Switches?
I hate to interrupt the IPv6 and RFC 1918 mega-threads... Does anyone know of a company that makes 208v (3-wire line-line ground, no neutral, 208v loads only, single phase) 30-60 amp automatic transfer switches with sub-30ms switching time? APC used to make the SU045X163 30A model, but it seems to have been discontinued and it's hard to find products that support 208v single phase. ~Seth
Re: Private use of non-RFC1918 IP space
Skeeve Stevens wrote: Owned by an ISP? It isn't much different than it is now. As long as you are multi-homed you can get a small allocation (/48), APNIC and ARIN have procedures for this. Yes, you have to pay for it, but the addresses will be yours, unlike the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share and hope we never interconnect/overlap. I can't find a RFC1918 equivalent for v6 with the exception of 2001:0DB8::/32# which is the ranges that has been assigned for documentation use and is considered to NEVER be routable. In that /32 are 65536 /48's... way more than the RFC1918 we have now. FD00::/8 ula-l rfc 4139 If I was going to build a v6 network right now, that was purely private and never* going to hit the internet, and I could not afford to be a NIC member or pay the fees... then I would be using the ranges above I wonder if that will start a flame war *puts on fire suit*.
Re: Automatic Switches?
Seth Mattinen wrote: I hate to interrupt the IPv6 and RFC 1918 mega-threads... Does anyone know of a company that makes 208v (3-wire line-line ground, no neutral, 208v loads only, single phase) 30-60 amp automatic transfer switches with sub-30ms switching time? APC used to make the SU045X163 30A model, but it seems to have been discontinued and it's hard to find products that support 208v single phase. Ugh, of course I come across something (TwinSource DCC-II RM-ITSTS, 50A in a 4U case using SCRs) mere minutes after posting. Any other recommendations are still welcome. The TwinSource unit looks quite fascinating, although I'm guessing quite expensive. ~Seth
