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, [email protected] 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 ([email protected]). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] if you experience any issues. >> > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. _______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
