On the second day of the meeting, John Curran gave a presentation on Government Affairs and Public Policy (slides). In this presentation he spoke about a meeting of Internet coordinating bodies he attended in Uruguay earlier this month. In this meeting, those assembled "called for the transition to IPv6 to remain a top priority globally. In particular Internet content providers must serve content with both IPv4 and IPv6 services, in order to be fully reachable on the global Internet."
This statement grabbed my attention. During the open microphone following his presentation, I posed the following question: "What can we do to encourage the content providers to step up their adoption?" This was his response:
"It's actually not that hard. If someone says they have something on the Internet and it's not v6 reachable, call them on it. It's only on a subset of the Internet. If you have a website and it's not v6 reachable, it's not on the Internet. It's only on a part of the Internet. If everyone in this room says that to everyone they meet, that will make a difference."For years many have been debating the chicken-and-egg scenario of which end needs IPv6 first: content or access? Of course the right answer is both, but many are reticent to be first movers. We have now reached a point where the content providers must step up to prevent a new NAT nightmare. Access providers are running out of IPv4 space. They are going to start needing to upgrade their equipment in order to continue to provide services to their users. If the primary source of the content those users are accessing is still IPv4 only, they will likely opt for Carrier Grade NAT (CGN) in lieu of upgrading directly to capable equipment. This is not a viable solution. NAT was originally created to give the Internet community time to perform the migration to IPv6. That time is about up.
If you are trying to enable your site to deliver content over IPv6 and having problems, let us know.
The full transcript of the session quoted in this post can be found at https://www.arin.net/participate/meetings/reports/ARIN_32/mem_transcript.html#anchor_5ReplyDelete