While SWIP assignments are used for determining the amount of addressses
in use, there is nothing in the current rules that would require reporting
this data down to the individual customer level in most cases.
As an example, most ISP's/LIR's provide each customer with a single IPv4
address for their use. This address may be either static or dynamic. In
any case, since this assigment is below /27, there is no requirement that
SWIP be done to the customer level. Such ISP could SWIP a block of
addresses used for dynamic customer addresses, showing them in use, but
not showing an individual record for each customer. Ditto with a block of
addresses used for static single address assignments. These collective
SWIP records show the addresses are being used, but do not require detail
down to the customer level.
In the dialup days of the past, blocks of addresses used for dial up pools
were commonly registered as one collective block. When these became
address pools for CTMS and DSL PPPoe, the same thing was often done,
registering the blocks to show their use, often showing what area in the
detail records. However, without an assignment of at least /27 to a
individual customer, there has never been a requirement to SWIP to the
customer level. Before 2013, that line was /24.
Because of the massive (compared to IPv4) blocks given out with IPv6, the
need for SWIP except for multihome and downstream ISP's may go away. My
experence is that many ISP's with v6 blocks have SWIP'ed nothing, and
since they are not going back to ARIN for more space, and having to
justify their current use, it is unlikely that SWIP in IPv6 will ever be
used to the extent it is in IPv4, since they are not seeking another bite
of the apple.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Thu, 30 Nov 2017, Owen DeLong wrote:
IMO, it is absolutely how the system should work.
Owen
On Nov 30, 2017, at 07:51 , Chris Woodfield <[email protected]> wrote:
One point to make on this proposal is that this may change how ISPs assign
blocks, given that both transfers and allocations have needs-based policies in
force (for both v4 and v6), and SWIPs are generally used as evidence of
utilization of existing blocks. With this proposal in force, adding a SWIP to
an allocated block should no longer be considered a parallel process to
assigning space to a downstream customer; instead, the insertion of a SWIP with
a validated POC will be a blocking function on the downstream allocation,
otherwise customers will be utilizing blocks without SWIPs if the POC is never
validated.
IMO this is how I feel the system *should* work, but then again, I???m
currently not in the business of doing these kinds of assignments. Those who
would be more directly impacted by this may have a different point of view :)
-C
On Nov 21, 2017, at 2:43 PM, ARIN <[email protected]> wrote:
On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-247: Require
New POC Validation Upon Reassignment" to Draft Policy status.
Draft Policy ARIN-2017-12 is below and can be found at:
https://www.arin.net/policy/proposals/2017_12.html
You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate
the discussion in order to assess the conformance of this draft policy with
ARIN's Principles of Internet number resource policy as stated in the Policy
Development Process (PDP). Specifically, these principles are:
* Enabling Fair and Impartial Number Resource Administration
* Technically Sound
* Supported by the Community
The PDP can be found at:
https://www.arin.net/policy/pdp.html
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
Regards,
Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)
Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment
Problem Statement:
Some large ISPs assign individuals to be POCs for reassigned blocks without
consultation of the individual they are inserting into Whois. One year later,
the POC is contacted by ARIN as part of Annual POC Validation policies. The
POC often does not know who ARIN is, what Whois is, and why they are in Whois.
This policy proposal seeks to improve the situation where a POC is unwittingly
and unwantingly inserted into Whois.
It also seeks to mitigate the significant amount of time that ARIN staff
reports that they spend fielding phone calls from POCs who have no idea they
are in Whois.
Finally, it is hopeful that this proposal will improve the overall POC
validation situation, by forcing ISPs and customers to work together to insert
proper information into Whois at the time of sub-delegation.
Policy statement:
Insert two new sections into NRPM 3:
3.7 New POC Validation Upon Reassignment
When an ISP submits a valid reallocation or detailed reassignment request to
ARIN which would result in a new POC object being created, ARIN must (before
otherwise approving the request) contact the new POC by email for validation.
ARIN's notification will, at a minimum, notify the POC of:
- the information about the organization submitting the record; and
- the resource(s) to which the POC is being attached; and
- the organization(s) to which the POC is being attached.
If the POC validates the request, the request shall be accepted by ARIN and the
new objects inserted into Whois. If the POC does not validate the request
within 10 days, ARIN must reject the request.
3.8 Downstream Validation of Simple Reassignments
When an ISP submits a valid simple reassigment request to ARIN with an
organization name OR postal address that is identical to one or more existing
OrgIDs, ARIN will notify the downstream organization and obtain guidance on
whether to accept the simple reassigment, or redirect it to one of the existing
OrgIDs as a detailed reassignment.
Comments:
Timetable for implementation: Immediate
_______________________________________________
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:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
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:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
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:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
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:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
