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 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 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 able
to have a CGnat at each site does not seem a good use of this block. This is
more than what was proposed for the regular waiting list, limited to a /22. The
goal of the block is for IPv4 connectivity until a future time when IPv4 is no
longer the primary transport on the internet. It was intended to be a shared
block, and not one where each user could have their own IPv4 address.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Mon, 15 Jul 2019, Owen DeLong wrote:
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
encourage feedback whether positive or negative in nature about this proposal
(though always constructive in any case).
Thanks,
Owen
Proposal text:
Problem Statement:
Currently, applicants for IPv4 resources under section 4.10 of the NRPM who do
so under a single OrgID of the NRPM may only obtain one /24 every six months
for the OrgID, even in the case where multiple discrete networks (MDNs) as
defined in section 4.5 of the NRPM are grouped under that OrgID. On the other
hand, where MDNs are held under different OrgIDs associated the same entity,
the six-month constraint would apply to each discrete network separately. This
results in unfair allocations of resources based solely on how entities choose
to associate MDNs with their OrgIDs. This policy rectifies that problem by
placing MDNs on an equal footing for the purpose of section 4.10 allocations
regardless of how they are grouped by OrgID by the same ultimate entity.
Policy Statement:
Bullet 1. under section 4.10 of the NRPM is amended to read:
the applicant may not have received resources under this policy in the
preceding six months, except to the extent that the applicant is r
equesting resources for a discrete network in respect of which it has not
received any resources under this policy in the preceding six months;
Add a new bullet 6 that reads:
An applicant requesting multiple allocations under this policy to support
Multiple Discrete Networks, as defined under Section 4.5, may not receive more
than the equivalent of a /21 of IPv4 address space in any one six-month period
hereunder.
Timetable for Implementation: Immediate
Anything Else:
To what extent should the passage of this policy be contingent or independent
of whether any ultimate cap is imposed on the total quantity of IPv4 resources
that an entity can obtain under section 4.10 regardless of the number of OrgIDs
associated with the entity or number of MDNs it holds.
==========
_______________________________________________
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.
