On Thu, May 16, 2019 at 1:38 PM David Farmer wrote:
[snip]
> Think about what you are asking, how does ARIN verify that, should they check
> the configurations of all your routers? Then you have to give it to them to
> check.
By requiring a similar level of information and review about the V6
On Thu, May 16, 2019 at 7:52 AM Fernando Frediani
wrote:
> Everything that is in the waiting list should be limited to a /22 per
request
I'm inclined to agree with this, at least the sentiment. If you "need" more
than a /22 but can somehow afford to wait around until ARIN fills it,
something is
On 5/16/19 11:41 AM, Fernando Frediani wrote:
> How does ARIN verify that people use IPv4 allocations in order to give
> them more addresses or let them keep the existing ones when a
> justification is required ?
>
> What was suggested is not that every host and application uses IPv6,
> this is
How does ARIN verify that people use IPv4 allocations in order to give
them more addresses or let them keep the existing ones when a
justification is required ?
What was suggested is not that every host and application uses IPv6,
this is unpractical. It is to use the same process that is
> On May 16, 2019, at 9:47 AM, hostmas...@uneedus.com wrote:
>
> Serving existing allocations is one thing.
>
> However, if someone wants ARIN to provide them NEW IPv4 space by the waitlist
> or transfer, I have no issue in tying that to at least having an IPv6
> allocation to go with the
On Thu, May 16, 2019 at 1:23 PM Alan Batie wrote:
> On 5/16/19 7:58 AM, Fernando Frediani wrote:
>
> > I like the idea of demonstrate IPv6 deployment in order to receive a new
> > IPv4 allocation
>
> FWIW, I also like this idea as long as it requires more than just a
> token network - the
On 5/16/19 7:58 AM, Fernando Frediani wrote:
> I like the idea of demonstrate IPv6 deployment in order to receive a new
> IPv4 allocation
FWIW, I also like this idea as long as it requires more than just a
token network - the current allocations should be IPv6 enabled (the
networks, not all the
> Michael Peddemors wrote :
> I personally dont' think ARIN's role should involve anything
> that can be construed as 'forcing' IPv6 adoption. While it
> might run counter to popular opinion, the idea of policies that
> encourage the 'killing' of IPv4 usage goes against the grain.
> Policies can
> Michael Peddemors wrote :
> Or we can just wait until IPv8 comes out, I hear it is twice as fast as IPv4
> ;)
Jim Fleming, come to our rescue ! :P
Michel.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public
Well, the question is simpler.
Among the rules applied to any RIR the issue IP allocation is that
people must prove they *at any time* are using the resources issued to
them or have need for that. If one received both IPv4 and IPv6 but is is
not using IPv6 then he is not observing these
Serving existing allocations is one thing.
However, if someone wants ARIN to provide them NEW IPv4 space by the
waitlist or transfer, I have no issue in tying that to at least having an
IPv6 allocation to go with the requested IPv4 space, along with at least
some effort to use that IPv6
On 2019-05-16 8:15 a.m., hostmas...@uneedus.com wrote:
IPv6 is the Future. We need our policies to help make it happen.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
Or we can just wait until IPv8 comes out, I hear it is twice as fast as
IPv4 ;)
All kidding aside, I
This is why I think all returns instead should go to the 4.10 IPv4 block
to facilitate IPv6 deployment, since everyone using this block must have
IPv6 in order to receive space from it.
The idea to take this returned space and serve the remaining wait list
with their minimum might be
100% IPv6 deployment is an utopia and will not happen not even in the
next decade for various reasons, therefore IPv4 is still needed for for
basic CGNAT, 464XLAT and other techniques that allows an ISPs or End
Users to exist in the Internet, therefore it is always better for more
people can
*Subject:* Re: [arin-ppml] Advisory Council Recommendation Regarding
NRPM 4.1.8. Unmet Requests
At 06:18 PM 5/15/2019, John Curran wrote:
On 15 May 2019, at 2:47 PM, Tom Fantacone mailto:t...@iptrading.com>> wrote:
> If we remove the waiting list activity of this one fraudster
On Thu, May 16, 2019 at 9:27 AM John Curran wrote:
Perhaps, one could say: that both the Marketplace and the Waitlist
are harmful to exist, since they discourage using IPv6 instead
by providing a "tempting solution" to the run-out situation that is not really a
solution --- the registry
after
Feb 7 2019 ( the date the suspension was posted) would be subject to the new
policy, whatever that may be.
Tom Pruitt
From: ARIN-PPML On Behalf Of Tom Fantacone
Sent: Thursday, May 16, 2019 9:01 AM
To: John Curran
Cc: arin-ppml
Subject: Re: [arin-ppml] Advisory Council Recommendation
On 16 May 2019, at 10:01 AM, Tom Fantacone wrote:
>
> At 06:18 PM 5/15/2019, John Curran wrote:
>> On 15 May 2019, at 2:47 PM, Tom Fantacone wrote:
>> > If we remove the waiting list activity of this one fraudster, how much
>> > "statistically likely" fraud is left?
>> > Was this one bad actor
At 06:18 PM 5/15/2019, John Curran wrote:
On 15 May 2019, at 2:47 PM, Tom Fantacone wrote:
> If we remove the waiting list activity of this one fraudster, how much
> "statistically likely" fraud is left?
> Was this one bad actor so bad that he accounted for almost all the likely
> fraud on the
Another reason why we shouldn’t allow IP blocks received via the
waitlist to be transferred to any other party aside for back to ARIN.
Sent from my iPhone
> On 15 May 2019, at 18:18, John Curran wrote:
>
>> On 15 May 2019, at 2:47 PM, Tom Fantacone wrote:
>> If we remove the waiting list
On 15 May 2019, at 2:47 PM, Tom Fantacone wrote:
> If we remove the waiting list activity of this one fraudster, how much
> "statistically likely" fraud is left?
> Was this one bad actor so bad that he accounted for almost all the likely
> fraud on the waiting list?
> Do we still even have a
Subject:
At their 16 January Meeting, the Board of Trustees suspended issuance of
number resources under NRPM section 4.1.8.2. (Fulfilling Unmet Needs),
and referred NRPM section 4.1.8 to the ARIN Advisory Council for their
recommendation.
The Advisory Council has provided its
22 matches
Mail list logo
