On Mon, Jul 15, 2019 at 11:17:48PM -0400, hostmas...@uneedus.com wrote:
> This means the ENTIRE BLOCK has been assigned to ARIN, and therefore
> ARIN controls the reverse DNS of this entire block.
I think you may be overstating the 'control' aspect. ARIN is part of a
chain of delegations. If we
Thanks Albert for such a comprehensive explanation and for going over
something that certainly most people understand well so didactically and
covering that "objection" completely.
I support that this fracturing of the reverse DNS is something
unnecessary and at the cost of not having to
I will take a stab at what this means.
I am choosing the block containing my IPv6 addresses as an example. If you
go to the ARIN whois site and look up network NET6-2600, you will see that
this network range is 2600:: to 260f:::::::.
This network is otherwise
On 7/13/2019 4:04 PM, John Curran wrote:
It is quite congruent, once you realize that ARIN cannot provide rights
to that which it does not control, so “exclusive use” granted is solely
with respect to the ARIN registry.
Which is why I have many times in the past harped on the importance
Dear Fernando,
On Mon, Jul 15, 2019 at 08:13:12PM -0300, Fernando Frediani wrote:
> I will comment only in one of the points, the other I believe are
> really well explained by others and it doesn't seem good to 'rain on
> the wet floor'.
I'm sorry but I don't think we can skip over some of
+1
Owen
> On Jul 15, 2019, at 14:23 , Scott Leibrand wrote:
>
> Allowing entities outside the ARIN region to continue holding addresses
> originally assigned to an ARIN-region organization to which the
> non-ARIN-region entity is a legal successor seems reasonable to me, and less
> fraught
I will comment only in one of the points, the other I believe are really
well explained by others and it doesn't seem good to 'rain on the wet
floor'.
On 15/07/2019 19:58, Job Snijders wrote:
- Readdressing is part of the business and not something prohibitive
Can you elaborate? I
On Mon, 15 Jul 2019 at 22:51, Fernando Frediani
wrote:
> I think regardless there would be an increase in the IPv6 routing table
> Inter-RIR transfers should not be allowed at all for the other given
> reasons as such:
>
> - Fracturing of Reverse DNS zone
>
Can you elaborate on the above? What
I think regardless there would be an increase in the IPv6 routing table
Inter-RIR transfers should not be allowed at all for the other given
reasons as such:
- Fracturing of Reverse DNS zone
- Complication of management of each /12
- No shortage of IPv6
- IPv6 migration and readdressing is
On Mon, Jul 15, 2019 at 2:27 PM wrote:
> It depends on if this is PI or PA space.
>
> In the case of PI space, you may be right, one route removed, one route
> added - net change likely zero. However in the long run, PI space is
> going to make the IPv4 routing tables look small when everyone
Could someone willing to have resources form ARIN, create a company in US,
subsidiary of a company in another RIR, justify the need, get the resources,
close the US company, and following this policy keep the ARIN resources?
I still think that ARIN-2019-10 (Inter-RIR M) makes more sense than
On Mon, Jul 15, 2019 at 4:07 PM Job Snijders wrote:
> On Mon, Jul 15, 2019 at 05:01:43PM -0400, hostmas...@uneedus.com wrote:
> > I understand that we allow this in IPv4 only because of the shortage.
> > Further, changing IPv6 addresseses is not as big of hardship as it was
> > in IPv4 land,
I support. In this case, it makes more sense to let them stay at ARIN.
On Mon, 15 Jul 2019, Scott Leibrand wrote:
Allowing entities outside the ARIN region to continue holding addresses originally
assigned to an ARIN-region organization to which the non-ARIN-region entity is a
legal
On Tue, May 21, 2019 at 11:02 AM ARIN wrote:
> Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion
>
> M activity sometimes results in a surviving legal entity that is not
> in ARIN service region, but may prefer to continue the pre-existing
> relationship with ARIN.
>
> Add the following
It depends on if this is PI or PA space.
In the case of PI space, you may be right, one route removed, one route
added - net change likely zero. However in the long run, PI space is
going to make the IPv4 routing tables look small when everyone has their
own route, rather than a combined
Allowing entities outside the ARIN region to continue holding addresses
originally assigned to an ARIN-region organization to which the non-ARIN-region
entity is a legal successor seems reasonable to me, and less fraught than
allowing IPv6 and IPv4 waitlist space to be M transferred to another
On Mon, Jul 15, 2019 at 05:01:43PM -0400, hostmas...@uneedus.com wrote:
> I understand that we allow this in IPv4 only because of the shortage.
> Further, changing IPv6 addresseses is not as big of hardship as it was
> in IPv4 land, since both networks can exist during a changeover
> period. Also,
I think fracturing the Reverse DNS zone, along with the PKI issues is not
worth allowing IPv6 transfers to happen. It needlessly complicates
management of each /12 IPv6 block which currently is 100% managed by ARIN,
and causes part of that space to be managed by another RIR.
I understand
It depends on the type of network.
A hosting infrastructure based in VMs, may be replicated "online" to another DC
in a different region.
The magic of that replication is a very good motivation for this policy, as
clearly doesn't make any sense that you can replicate everying including no
On Tue, May 21, 2019 at 12:52:11PM -0700, Seth Mattinen wrote:
> On 5/21/19 11:02 AM, ARIN wrote:
> > Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion
>
>
> Also oppose.
Seth,
Can you expand on your reason for opposition?
Cheers,
Joe
--
Posted from my personal account - see
Hey folks,
Like several other proposals, we seem to have been
hit by the summer slump considering the following.
There was a single posted objection, and it isn't
clear if lack of activity stems from
- uninterest
- interest in seeing 2019-13 move instead
- interest in seeing 2019-4 move
Agreed. Well said.
Sent from my iPhone
On Jul 15, 2019, at 15:46, Nick Bogle wrote:
I am in favor of this change. As a company that has multiple discrete
networks that have no realistic way of connecting them, one site gets
NAT64, then another site gets NAT64, but each site has to wait 6
I am in favor of this change. As a company that has multiple discrete
networks that have no realistic way of connecting them, one site gets
NAT64, then another site gets NAT64, but each site has to wait 6 months
before getting this capability. No one is going to realistically announce
less than a
I did find the RIPE-682 document, and I do see that RIPE allows IPv6
transfers.
However, I still do not think this is a good idea for ARIN. It adds an
extra level of complexity to both the reverse DNS zone and PKI.
Therefore, I am still opposed to allowing IPv6 RIR transfers from ARIN
All networks receiving 4.10 space must have IPv6 connectivity in order to
receive the 4.10 space. This IPv6 connectivity can be used to connect
each site to the central CGnat.
Albert Erdmann
Network Administrator
Paradise On Line Inc
On Mon, 15 Jul 2019, Scott Leibrand wrote:
If an
Yes… It would be nice if RIPE would move to a system similar to the other RIRs
where there
is a single comprehensive policy document which is amended through the PDP
rather than
their current RFC (usually without the back references and without the
advantages of a
responsible RFC editor
If an organization runs multiple discrete networks, how do you propose that
they NAT each site without IPv4? Discrete networks, by definition, do not have
internal connectivity between them.
Scott
> On Jul 15, 2019, at 12:03 PM, hostmas...@uneedus.com wrote:
>
> I am opposed.
>
> This space
I fully agree with the comments on below message.
Fine IPv4 and 16 bit ASN transfers but not to IPv6.
Some people justify that it is to avoid renumbering, but I don't
consider a strong enough reason to allow IPv6 transfers. Renumbering is
part of the business whenever necessary and not
Hi Albert,
I think you looked at the wrong RIPE documents. Unless I got it wrong, the
right document is RIPE-682, and it clearly states that IPv6 can also be
transferred (both intra and inter-RIR).
I've a similar policy proposal in LACNIC and APNIC, and working as well for
submitting in a few
Apologies for missing your comment Scott. It fell through my manual search.
This is an excellent observation and suggestion for the community to
consider. I look forward to hear more from you and others.
Warm regards
Kerrie
On Jul 15, 2019 1:51 PM, "Scott Leibrand" wrote:
> On June 18 I
I am opposed.
This space is to allow IPv6 networks access to IPv4 resources so that the
users on these networks can connect to IPv4 resources.
Current practice for CGnat generally use a block of 4.10 IPv4 resources to
provide such interconnect for many /64 networks. Giving them a /21 to be
I vote in favour as well. It has a direct impact on our organisation as we
keep all our IP blocks under one OrgID and have had trouble getting access
to IPv4 for our dual stacked sites.
Sent from my iPhone
On Jul 15, 2019, at 14:52, Scott Leibrand wrote:
I am in favor of this change. We should
I am in favor of this change. We should be encouraging people to use NRPM
4.10 where applicable instead of sitting on the general waiting list.
-Scott
On Mon, Jul 15, 2019 at 11:44 AM Owen DeLong wrote:
> Hello, everyone.
>
> The AC is currently considering this draft policy which would
The only problem I have with this policy is that allows IPv6 transfers.
I have no problem with IPv4 and 16 bit ASN transfers because they are both
scarce resources. However, I do not think we should start down the road
of allowing IPv6 RIR transfers. If they are operating in a portion of the
On June 18 I commented that "It would probably also provide a way to bypass
ARIN policy, so we should think carefully about whether all resources (such
as waiting list space) should be transferable this way."
Would it be better to limit the applicability of ARIN-2019-10 to only apply
to space
Hello, everyone.
The AC is currently considering this draft policy which would provide for
Multiple Discrete Networks to be able to get more than one block under 4.10 for
up to 8 discrete sites within a six month period.
So far, there has been little comment on the list. The AC would like to
Good day everyone,
I am seeking community input on *Draft Policy ARIN-2019-10: Inter-RIR
M *since the last post on this policy on May 21, 2019 there has not
been any conversation around it. As primary shepherd I need to have a
good sense of the direction that the community wants to take in
I support this revised version of draft policy ARIN-2019-9 as written.
Brian
On Thu, May 23, 2019, 12:44 PM ARIN wrote:
> The following has been revised:
>
> * Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6
> Transition Space Requests and NRPM 4.1.8.2 Unmet Needs
All - We haven't received a lot of comments on 2019-9. If you have time
today, could you please comment for or against moving forward with this
policy? Do you feel this proposal would remove the potential for duplicate
requests under these sections? Thank you in advance for any comments
Kat
Carlton- thank you for your comment.
All- Our Advisory Council meeting is this Thursday and I'd like to see if
we can get any additional comments for moving this forward. If there are no
comments, I will be moving this to a vote on the AC to get this in
recommended status. Thanks
Kat Hunter
On
40 matches
Mail list logo
