97.128.0.0/9 allocation to verizon wireless

> NAT? why isn't Verizon 'It's the Network' Wireless using IPv6?
> <speaking-from-ass>there 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

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)

Hint: how many of the (say) Alexa top 1000 websites are IPv6 enabled?

Regards,
-drc

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

David Conrad 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 (AAAA)
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. :wink:

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:ffff::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:ffff::3:c9a2

Mike.

Plus the rest of their space, at least the easily identifiable portions.
It's extremely difficult to speculate what people are doing with large
amounts of addresses. I trust that ARIN has done the right thing in
accordance with community standards. V6 addresses included.

They may want to not recycle that template containing the comment again. It
showed up on the last two allocations.

Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK
(NET-66-174-0-0-1
<http://ws.arin.net/whois/?queryinput=!%20NET-66-174-0-0-1>)
66.174.0.0 <http://ws.arin.net/whois/?queryinput=66.174.0.0> -
66.174.255.255 <http://ws.arin.net/whois/?queryinput=66.174.255.255>

Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK
(NET-69-82-0-0-1
<http://ws.arin.net/whois/?queryinput=!%20NET-69-82-0-0-1>)
69.82.0.0 <http://ws.arin.net/whois/?queryinput=69.82.0.0> -
69.83.255.255 <http://ws.arin.net/whois/?queryinput=69.83.255.255>

Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK
(NET-69-96-0-0-1
<http://ws.arin.net/whois/?queryinput=!%20NET-69-96-0-0-1>)
69.96.0.0 <http://ws.arin.net/whois/?queryinput=69.96.0.0> -
69.103.255.255 <http://ws.arin.net/whois/?queryinput=69.103.255.255>

Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK
(NET-70-192-0-0-1
<http://ws.arin.net/whois/?queryinput=!%20NET-70-192-0-0-1>)
70.192.0.0 <http://ws.arin.net/whois/?queryinput=70.192.0.0> -
70.223.255.255 <http://ws.arin.net/whois/?queryinput=70.223.255.255>

Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK
(NET6-2001-4888-1
<http://ws.arin.net/whois/?queryinput=!%20NET6-2001-4888-1>)
2001:4888:0000:0000:0000:0000:0000:0000
<http://ws.arin.net/whois/?queryinput=2001:4888:0000:0000:0000:0000:0000:0000>
- 2001:4888:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
<http://ws.arin.net/whois/?queryinput=2001:4888:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF>

Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK
(NET-97-128-0-0-1
<http://ws.arin.net/whois/?queryinput=!%20NET-97-128-0-0-1>)
97.128.0.0 <http://ws.arin.net/whois/?queryinput=97.128.0.0> -
97.255.255.255 <http://ws.arin.net/whois/?queryinput=97.255.255.255>

Cellco Partnership DBA Verizon Wireless WIRELESSDATANETWORK
(NET-174-192-0-0-1
<http://ws.arin.net/whois/?queryinput=!%20NET-174-192-0-0-1>)
174.192.0.0 <http://ws.arin.net/whois/?queryinput=174.192.0.0> -
174.255.255.255 <http://ws.arin.net/whois/?queryinput=174.255.255.255>

Best,

Martin

We're not a big verizon wireless customer, (we have been allocated a /25
for remote data access devices). We run multi-homed BGP with vw. vw says
that they must advertise 48 summarized prefixes to us, instead of just
the /25. The 48 prefixes are apparently advertised to all of the
de-aggregated users contained in the summarized 48 prefixes. Is this a
common practice? If so is it a best practice?

Mark Andrews schrieb:

  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.

OTOH, Verizon is not the only provider of smartphone connectivity in the
world. Most of them try to be "good citizens" and do not waste a scarce
resource (IPv4 space).

If more providers would act like Verizon, we would have run out of IPv4
addresses a long time ago (whether or not that is a good or bad thing is
left as an exercise to the reader).

-- Matthias

You mean like the 10.x.x.x addresses give to all iPhones in the US?

Wait, I thought NAT was bad? So who is the "good citizen"?

I disagree that using global IPv4 space is a "waste". Every device
deserves to have "real" internet connectivity and not this NAT crap.

Chuck Anderson wrote:

You're almost always better off not providing a user-accessible switch.
Especially not a shiny one labeled "Do not touch unless you know what
you are doing".

(FWIW, this is exactly the same issue as "block port 25 unless user requests
opt-out from the block")

Lots of providers do. Sometimes the choice between static & dynamic is bundled with the choice between NAT & "real" on some broadband providers.

I've also seen hotels do it, and even charge extra for it. (Yes, I paid. :wink:

Patrick W. Gilmore wrote:

Many/most GSM/GPRS/etc operators will have multiple APN's - one which is
setup for NAT, and the other which gives a public IP address.

By default, most "dumb" phones will use the former. Data cards will use the
latter, and smartphones seem to be split between the two - although
obviously it will vary between providers.

  Scott.