And ipv4 I presume so there is still easier and cost less money to just go with that.
From our point as an MSP no customer has a requirement that they want to be able to be reached via IPV6 so it’s still cheaper to buy up IPV4 address space and do a lot of nat than to convert all our services to function properly with IPV6.
Sure one could argue that they should have been made that way from the beginning but without customer demand why would we spend the money?
//Gustav
I think you will find that there are some places in which getting IPv6 network service has been difficult, and as a result even IPv6-
Fred, do you mean places like, all of Verizon FiOS?
Bryan,
Even the DNS root servers are not 100% reachable via IPv6.
Excepting temporary failures, they are as far as I am aware. Why do you
think they aren’t?
I can't reach C, 2001:500:2::c, from many places in v6 land. My home and
secondary data center can't reach it, but my backup VM's at another data
center can.
<snip>
However, the IANA team is not the enforcement arm of the Internet. If a
root server operator chooses to not abide by RFC 7720, there is nothing the
IANA team can do unilaterally other than make the root server operator
aware of the fact.
Surely IANA has the power to compel a root server operator to abide by policy
or they lose the right to be a root server?
Until IPv6 becomes provides a way to make money for the ISP, I don't see
it being offered outside of the datacenter.Different markets, different approaches. In the areas I’ve lived in Los
Angeles, commodity residential service via AT&T (1 Gbps up/down fiber) and
Spectrum (varying speeds) is dual stack by default (as far as I can tell).
I suspect all it would take would be one of the providers in your area to
offer IPv6 and advertise the fact in their marketing to cause the others to
fall into line.
Prior ISP charged me $15/month per IPv4 address and a mandatory router rent of
$10/month. New one gets $5/month per IPv4 address. The reason for this is IP
scarcity. They have plenty of v4 space, so this allows them to charge for it.
v6 isn't going to make them any more money as they can't charge for it.
Mobile is different, v6 makes financial sense as CG NAT doesn't scale to 400m
cell phones in north America. (does NANOG scope include Mexico?)
That said most (all) IPv6 cellular providers still don't use it for end to end
connectivity, as inbound connections are silently dropped. In the US if you
want inbound connectivity to work via cellular, you must to buy the static IP
service from Verizon, and it has no IPv6 support, and no plans for it in the
future.
Oddly enough the MVNO services over T-Mobile seem to allow inbound IPv6, but
TMO proper doesn't. V6 that works everywhere would simplify a _huge_
connectivity problem for me.
Sent using a machine that autocorrects in interesting ways…
I think you will find that there are some places in which getting IPv6 network service has been difficult, and as a result even IPv6-
Fred, do you mean places like, all of Verizon FiOS?
That would be an example. If I traceroute to an ipv6 address, the fact that I get a response is proof that the path works. F root has some servers for which, MOU be damned, there is no working IPv6 path. Mumble…
Ca By wrote:
First, consider that the 3 major cell carriers in the usa each have
100 million customers. Also, consider they all now have a home
broadband angle. Where do 100 million ipv4 addresses come from? Not
rfc 1918, not arin, … and we are just talking about customer ip
addresses, not considering towers, backend systems, call centers,
retail ….
Are you saying mobile terminals must be identified by IP addresses?
Masataka Ohta
Ca By wrote:
First, consider that the 3 major cell carriers in the usa each have
100 million customers. Also, consider they all now have a home
broadband angle. Where do 100 million ipv4 addresses come from? Not
rfc 1918, not arin, … and we are just talking about customer ip
addresses, not considering towers, backend systems, call centers,
retail ….Are you saying mobile terminals must be identified by IP addresses?
Nodes in an ip network require ip addresses. 4G and 5G are ip networks for both voice and data.
I do not believe it is either technically nor economically feasible to run a 4g or 5g network without an ip address on the ue.
Ummh, how else do you expect a player on the Internet to, ummh, play?
Mark.
shaking_my_head For the avoidance of doubt, Cameron is speaking sense. Mark.
Ca By wrote:
I do not believe it is either technically nor economically feasible
to run a 4g or 5g network without an ip address on the ue.
So are IP entities behind NAT. So?
Masataka Ohta
Your point being...?
Mark.
I’m typing this on an LTE UE on our network with a NAT’d IPv4 IP address.
Feels relevant.
—L.B.
Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
6x7 Networks & 6x7 Telecom, LLC
CEO
lb@6by7.net
"The only fully end-to-end encrypted global telecommunications company in the world.”
FCC License KJ6FJJ
We may be missing each other here...
From the point of view of TCP/IP, a node behind a CGN has a unique IP address.
So what I'm trying to understand is, despite whether a connection is pure or NAT'ed, how does a device on the Internet expect to communicate without an IP address?
Mark.
Mark Tinka wrote:
So what I'm trying to understand is, despite whether a connection is
pure or NAT'ed, how does a device on the Internet expect to
communicate without an IP address?
So are IP entities behind NAT. So?
Masataka Ohta
Some of the other CDNs do have IPv6 on the authorities and
should work without issues.
eg:
dig -6 +trace www.akamai.com.
- Jared
I still don't understand your point.
Are you asserting that NAT'ed devices do not have an IP address?
Mark.
Bryan,
Excepting temporary failures, they are as far as I am aware. Why do you
think they aren’t?I can't reach C, 2001:500:2::c, from many places in v6 land. My home and
secondary data center can't reach it, but my backup VM's at another data
center can.
Ah. Cogent. I suspect IPv6 peering policies. Somebody should bake a cake.
However, the IANA team is not the enforcement arm of the Internet. If a
root server operator chooses to not abide by RFC 7720, there is nothing the
IANA team can do unilaterally other than make the root server operator
aware of the fact.Surely IANA has the power to compel a root server operator to abide by policy
or they lose the right to be a root server?
To compel? No. Not in the slightest. That is not how the root server system works. This is a (very) common misconception.
There has been some effort to create a governance model for the root server system (see https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) but I believe it has gotten bogged down in the question of “what do you do when a root server operator isn’t doing the job ‘right’ (whatever that means and after figuring out who decides) but doesn’t want to give up being a root server operator?”. It’s a hard question, but it isn’t the folks at IANA who answer it.
Regards,
-drc
Surely IANA has the power to compel a root server operator to abide by
policy or they lose the right to be a root server?To compel? No. Not in the slightest. That is not how the root server system
works. This is a (very) common misconception.
Can you explain how it would work? Say you have a root server operator who
starts messing up, is there any ability to remove them?
There has been some effort to create a governance model for the root server
system (see
https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) but I
believe it has gotten bogged down in the question of “what do you do when a
root server operator isn’t doing the job ‘right’ (whatever that means and
after figuring out who decides) but doesn’t want to give up being a root
server operator?”.
Seems like a good policy, 6.3 seems to cover how to fix technical issues with
a root operator.
It’s a hard question, but it isn't the folks at IANA who answer it.
Who does? Doesn't IANA designate root servers and the . zone?
Bryan -
One of the things that was clarified with the IANA Stewardship Transition is that ICANN has (at least) two distinct roles contained within it: one is coordination of the domain name community to develop Domain Name policy and the other is the IANA / Public Technical Identifiers (PTI) role serving as operator of the IANA functions (i.e. performing the administration of the various DNS, protocol registries, and the Internet numbers registries)
The IANA doesn’t set policy, but rather takes policy for each set of identifiers from the respective community: a) ICANN DNS Community for the DNS root zone, b) IETF for the protocol parameter registries, and c) the RIRs for the unicast IPv4, unicast IPv6, and ASN registries listed in IETF RFC 7249. David is definitely correct to say that determining what (if any) governance model should be utilized for the root server operators is a question outside the scope of the administrative/technical operations performed by the IANA/PTI, and rather a question that the various DNS stakeholders (DNS community, ICANN, IETF, and the Root Server Operators) must ponder.
/John
