That statement is true now, but will not stay that way.
On the residential side and even small business, I can see IPv4 public
addresses becoming a "value added" service at an additional cost, with
those without it sharing IPv4 public addresses via CGnat, or even an IPv6
only tier promoted for IPtv like Netflix, but saving the provider the cost
of CGnat for that customer, thus offered at a discount.
On the consumer side, the big bandwith things (Netflix, Google, Facebook,
Microsoft, etc.) are already on IPv6, and those with a dual stack
connection are already sending and receiving the majority of their bits by
IPv6. This will drive this portion of the market demand for additional
IPv4 addresses down compared to the Build or Buy side of the enterprise
market.
This proposal is to get those who want to expand their IPv4 holdings to
dip their toes into the IPv6 pool. It is not directed at the big boys that
are already there. Once they adopt some IPv6, the advantages to them will
be made more clear, and the rest of their movement may happen voluntary.
It also has an effect on enterprise customers whose CxO's do not want to
spend money on "unneeded" things. Once IT tells management that they
cannot get any more IPv4 addresses without placing some IPv6 in place,
they will get support for adding IPv6 from the bean counters. As long as
IPv6 is considered "Optional", a lot of Orgs will not spend the money on
it regardless of merit.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Mon, 11 Nov 2019, David Farmer wrote:
If it is the case that "the vast majority of the current directed transfers are
landing in the hands of the major ISP's and Mobile carriers, who have already taken a
large step toward IPv6 deployment," Then my question is how is this policy
going to be effective in moving the needle for the deployment IPv6?
My primary concern regarding this policy is efficacy, will this policy actually
increase the deployment IPv6? If not, why are we considering it? Your statement
quoted
above to me calls into question how effective this policy can be.
Thanks
On Mon, Nov 11, 2019 at 4:09 PM <hostmas...@uneedus.com> wrote:
Yes, this would be a good idea based upon the current IPv4 utilization
policy, just without a specific percentage of IPv6 use.
This would be a stronger step and statement to IPv6 adoption. In reality,
I suspect that the vast majority of the current directed transfers are
landing in the hands of the major ISP's and Mobile carriers, who have
already taken a large step toward IPv6 deployment, by using it in all
network elements that they control. Any slowness in adoption is often due
to Customer Provided Equipment that does not support IPv6. Newer standards
like DOCSIS 3+ and 5G already mandate IPv6. Customer movement to these
technologies to obtain more speed will drive even more IPv6 adoption. The
documentation of their effort is often already available to ARIN.
As to cost, every bit of traffic that is pushed to IPv6 represents a large
portion of traffic that does not have to use expensive network elements
such as Carrier Grade NAT because of lack of public IPv4 addresses.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Mon, 11 Nov 2019, Fernando Frediani wrote:
> Hello Albert
>
> Reading some comments about the proposal one thing that has been
highlighted
> is that the mechanism proposed to show IPv6 is operational is simply
being
> able to communicate to ARIN could be easily fooled I wanted to suggest
a text
> adjustment in order to make it more effective and still objective for
ARIN
> staff to be able to do this check.
>
> The new text could be something like: "Such operational network must at
> minimum include an allocation or assignment by ARIN of IPv6 address
space
> under the same Org ID receiving the transferred IPv4 space. Such Org
must be
> able to prove this IPv6 space is being routed by using it to
communicate with
> ARIN and by providing ARIN the documented network deployment details to
prove
> IPv6 is operational."
>
> This is not something new to be done as it is similar that the
justification
> process which has always been done for IPv4, with the specific
differences.
> It's important to highlight that this doesn't mean one must prove it
has 100%
> IPv6 deployment, but rather that it is operational and in fact in used
by
> internal devices, staff, customers, etc rather than just announced to
the
> internet and used in a single tiny network just for Internet browsing.
> I think is reasonable to trust ARIN staff to evaluate at their
discretion as
> three is precedent in the NRPM and it is not very difficult to
differentiate
> both scenarios. In short words, a commitment to IPv6 and having it
> operational doesn't mean 100% deployment.
>
> Best regards
> Fernando
>
> On 11/11/2019 17:34, hostmas...@uneedus.com wrote:
>> I have a request for any numbers on IPv6 adoption of those who have
>> received directed transfers in the last year, or any other available
>> period.
>>
>> I have looked at some of the blocks that have been transferred, and
most of
>> them seem to be obtained by larger ISP or Mobile Wireless providers
that
>> are already well known adopters of IPv6. Such providers would of course
>> have no issues meeting the standards of the Draft Policy.
>>
>> What I would like to find out is what percentage are in the position
of not
>> having any IPv6 in place, and therefore might be adversely affected.
>>
>> Thanks,
>>
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>>
>> On Thu, 7 Nov 2019, Owen DeLong wrote:
>>
>>>
>>>
>>> On Nov 6, 2019, at 13:40 , Fernando Frediani
<fhfredi...@gmail.com>
>>> wrote:
>>>
>>> I wanted to kindly request AC members attention to all objections
based on
>>> the argument that "ARIN is forcing someone to do something on their
own
>>> network”.
>>>
>>>
>>> This is NOT true at all and not the propose of this proposal
therefore I
>>> believe these kind of objections have been refuted multiple times
already.
>>>
>>>
>>> I cannot speak for the entire AC, but this AC member (at least until
the
>>> end of the year) is well aware of your position on the matter. I do
not,
>>> however,
>>> share this opinion.
>>>
>>> Insisting that people make an IPv6 address pingable in order to
receive
>>> IPv4 resources via transfer strikes me as an effort to push those who
do
>>> not wish to
>>> do IPv6 into doing so.
>>> As such, it is about forcing someone to do something on their own
network.
>>>
>>> This is a valid objection to the policy. It may be an objection the
>>> community decides to overrule or dismiss, but it is an objection,
>>> nonetheless.
>>>
>>> You may not like that objection, and that’s fine. You’ve said so, and
>>> we’ve heard you.
>>>
>>> With regards the proposal this community has the right to
estabilish
>>> whatever conditions for the RIR registration related stuff it finds
better
>>> for the RIR and the Internet to continue working healthy in the
>>> region.
>>>
>>>
>>> This is also true, but the people you are dismissing because you don’t
>>> like their objections are just as much members of the community as you
>>> are. They have
>>> every right to object to the policy on whatever basis they feel is in
>>> their best interests or that of the community.
>>>
>>> For example the increasing cost imposed to all others by those
who
>>> wishes to remain in the past and the growing conflicts due to the
current
>>> scenario are good point for this community to evaluate.
>>>
>>>
>>> Here, I agree with you. I don’t agree that what is proposed will help
>>> resolve that issue. I do think we will have many discussions about
how to
>>> resolve this
>>> particular problem in the coming years.
>>>
>>> Also I am finding some people having trouble with the mechanism
to
>>> validate IPv6 is operational and would really like to hear other
points of
>>> view about more effective way that process can be validaded and
be
>>> more effective in their point of view.
>>>
>>>
>>> This is a very tough question. I think that all of the corner cases
that
>>> would exist in response to this question are a perfectly valid reason
not
>>> to
>>> inflict this proposed policy on the community.
>>>
>>> Owen
>>>
>>>
>>> Regards
>>> Fernando
>>>
>>> On Thu, 7 Nov 2019 16:06 Brett Frankenberger,
<rbf+arin-p...@panix.com>
>>> wrote:
>>> On Wed, Nov 06, 2019 at 12:55:50PM -0500, ARIN wrote:
>>> > On 1 November 2019, the ARIN Advisory Council (AC) accepted
>>> "ARIN-prop-278:
>>> > Require IPv6 Before Receiving Section 8 IPv4 Transfers" as a
Draft
>>> Policy.
>>> >
>>> > Draft Policy ARIN-2019-19 is below and can be found at:
>>> >
>>> > Policy statement:
>>> >
>>> > In section 8.5.2, add the following language to the end of the
>>> paragraph
>>> > entitled “Operational Use”:
>>> >
>>> > Such operational network must at minimum include an
allocation or
>>> assignment
>>> > by ARIN of IPv6 address space under the same Org ID receiving
the
>>> > transferred IPv4 space. Such Org must be able to prove this
IPv6
>>> space is
>>> > being routed by using it to communicate with ARIN.
>>> >
>>> > In the event the receiver provides a written statement from
its
>>> upstream
>>> > that IPv6 connectivity is unavailable, the IPv6 requirement
may be
>>> waived.
>>>
>>> Opposed for multiple reasons.
>>>
>>> First, it should not be ARINs role to dictate the manner in
which
>>> networks are operated. We have routinely resisted the notion
that,
>>> for
>>> example, spammers should have resources revoked. Now we're
>>> proposing
>>> to deny resources to networks that decide not to operate IPv6.
>>>
>>> Second, the proposal is premised on the idea that IP addresses
are
>>> solely allocated for the purpose of operation on the public
network,
>>> despite policy being clear that that's not the case. While
that's
>>> certainly the predominate use case, there is nothing that
prevents a
>>> private interconnected network from operating on
>>> ARIN-assigned/allocated public space without connecting to the
>>> Internet. Are we proposing to deny any future transfers for
such
>>> networks? They would by their nature be unable to prove IPv6
>>> connectivity to ARIN (except as a stunt -- see below) and would
be
>>> unable to get a statement from their upstream (since they would
have
>>> none) as to the availability of IPv6 connectivity.
>>>
>>> Third, this encourages meaningless stunts. A network that does
not
>>> desire to opreate V6 is not going to reconsider that decision
as a
>>> result of this policy. At best, they will get an IPv6
allocation or
>>> assignment from ARIN, route it to one subnet, put a device on it
>>> long
>>> enough to perform whatever ceremony ARIN requires to prove IPV6
>>> connectivity, get their transfer, and then shut it down (or
maybe
>>> leave
>>> it there in case they have to reperform the ceremony should they
>>> transfer additional addresses in the future). More likely, this
>>> will
>>> cause the creation of a new industry: organizations needing to
>>> complete
>>> an IPv6 connectivity validation to get a IPv4 transfer processed
>>> will
>>> sign a LOA granting their Ceremony Consultant the right to
announce
>>> their IPv6 allocation/assignment long enough to complete the
>>> ceremony,
>>> and their consultant will do all the work necessary to get the
>>> required
>>> box checked in ARIN's systesm.
>>>
>>> This will not drive IPv6 adoption. I oppose the use of ARIN or
>>> community resources on stunts, and I oppose the creation of a
"IPv6
>>> Ceremony Consultant" industry.
>>>
>>> -- Brett
>>> _______________________________________________
>>> ARIN-PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact i...@arin.net if you experience any issues.
>>>
>>> _______________________________________________
>>> ARIN-PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact i...@arin.net if you experience any issues.
>>>
>>>
>>>
>>>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
--
===============================================
David Farmer Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
