I did not attend ARIN39, but did watch the video of the discussion
regarding this Draft Policy. I have looked thru the archives, and have
not seen any previous discussion of 2017-3 since its announcement, thus I
start the discussion on the list.
I am in favor of the policy changes, except for
I am opposed to this as well, unless the resources are in fact revoked and
reassigned, which in fact, as to legacy resources is never going to
happen.
While strictly speaking ARIN does not "have" to provide the reverse
records, the legacy holders could argue in court that the service was
alwa
So in effect, all the proposed 3.6.4 does is to formalize what is the
current practice of allowing the change. Thus, there should be no
problems with the change.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Wed, 10 May 2017, John Curran wrote:
On 10 May 2017, at 2:34 PM, J
Just as a point of information, can someone from ARIN tell us under what
conditions (if any) is the POC or the rDNS pointers removed under the
current policy? I was doing a bit of looking, and I assume that in any
case this policy can only affect legacy class B and C holders, as it
appears tha
Hello,
The line has to be drawn somewhere, and the idea when I drafted this
proposal was that it was wrong to treat IPv6 less favored than IPv6 as is
the current case. It also bothered me that the average residential and
small business account would have to go thru the SWIP process, just
bec
This proposal was intended to try to bring the v4 and v6 world together on
the same policy. Because of the nibble boundary rule and rDNS, on the v6
side, there are really only 5 choices in network size: /48, /52, /56, /60
and /64 without having to do non-standard CNAME tricks used when
subdivi
When either these new SWIP rules, for IPv6, or the current SWIP rules,
for IPv4 are violated... as they appear to be, with great frequency,
from where I am sitting... then who does one call? The Internet Police?
The only real "Police" is when ARIN uses the SWIP data to justify another
allocat
So, let me see if I understand this...
ARIN doesn't, can't, and most probably won't either enforce the existing
(IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may be
drafted and/or promulgated with respect to IPv6. Is that about the size
of it?
If so, then color me perplexed.
On Fri, 26 May 2017, Ronald F. Guilmette wrote:
In message ,
hostmas...@uneedus.com wrote:
Only the largest IPv4 customers are subject to SWIP, not the majority of
the total customer base.
Just when I though that I was beginning to understand, now I am *really*
confused. You say "Only the
I dont think that ARIN has actually made any attempt to define
"Residential Customer", but the term seems to imply the person, not the
place. For example, If I live at my business, I think I could still be a
"Residential Customer". I know under the old days of landline telephone
that private
Well, assuming everything is legit, maybe those last stars on the
traceroute belong to a point to point link between Dallas and Riga :)
Of course the more likely course is that this block points to a server in
that datacenter, and by the definition is not a "Residential Customer".
The only rea
This idea kinda misses the entire point of what I seek to do with this
proposal.
The entire reason for my proposal is to make v6 equai or better than v4
when it comes to assignment registrations or SWIP. Since the smallest
possible v6 network is /64, the current policy requires ALL v6 custome
1) According to the policy manual, it appears that SWIP is the tool for an
ISP to document the address assignments made to its customers, so that
when more address space is requested, ARIN can determine qualifications.
2) Although not directly expressed in the policy manual, it is also a tool
I was always under the impression that the DMCA requires all notices go to
the address registered for the domain with the Copyright Office under
17 USC 512(c)(2).
I would not think that using a SWIP'ed contact address for DMCA purposes
would be lawful, unless the URL used only an IP address, a
As the author of this Draft Policy, I can now see the IPv4 change has
little/no support. I included it originally to give equality to both v4
and v6 with more than 16 ip4 addresses or 16 ip6 networks.
I have asked the AC to remove the IPv4 language from the proposal
(4.2.3.7.1), leaving only
I think the true reason the ARIN blockholder gets the notice is that whois
lookups can be automated, and it is a bit harder to automate a lookup in
the correct library of congress copyright database. Connectivity
providers that actually do not host should not be getting these notices at
all, b
I for one do not see why a suggestion is HORRIBLE.
Of course, SWIP, like any other issue is not black and white. There is a
big difference between the current policy of requiring the registration of
/29 or more of v4 and /64 or more of v6, and a different suggestion to ban
SWIP servers.
I s
If enforcement of SWIP would result in the elimination of network abuse, I
would not speak against it. However, even with valid contacts in SWIP,
abuse reports are ignored. Contacting the ARIN allocation holder also
often goes unanswered as well, and this is not dependent on SWIP. In
addition
After seeing the vast majority of commenters agreeing to /56, I am
changing my vote from any level stated to more than a /56.
As the author of the Draft, I have been following the comments. With my
vote, /56 has 11 votes. There are also 2 people who are in agreement with
any of the expressed
Well, when I say nothing is done, I mean the abuse continues after the
report is made to the contact listed in SWIP/WHOIS.
If you were the administrator and you did what you said after a report, I
would see the abuse stopped (in this case simply beacuse you cut that user
off), I would consider
I am opposed to the Draft Policy ARIN-2017-2 for community networks, as I
do not think the community network language should be removed from the
Policy Manual. Instead, the policy should be fixed to allow its use.
In order for the policy to be useable, amendments need to be made to the
policy
Considering the reaction the Community gave to the first version of this
draft policy regarding SWIP changes for IPv4, and the near universal need
to keep the v4 SWIP boundary where it is currently at 8 ip's or more, I
doubt there is much support for SWIP elimination. This is why I asked to
st
I have been using v6 since 2007, and everything that was ever stated in
the RFCs and in practice always recommended that assignments align on a
nibble boundary. Having had many v4 assignments less than /24, I know of
the CNAME tricks used. I never had a non nibble aligned v6 assignment, as
I
I caution this writer and anyone else responding to Draft Policy
ARIN-2017-2 of the following:
Anyone in FAVOR of ARIN-2017-2 is in favor of elimination of all language
that is currently in the policy manual regarding community networks.
The comments below seem to be in favor of some kind of
Doing a bit of reading the policy manual this weekend, it appears the main
thing it does is to treat a Community Network like an end user rather than an
ISP/LIR in regard to receiving v6 resources. It also appears that almost any
Community Network could already qualify for v6 space as an end us
I also do not support this policy.
As pointed out, there are at least 2 blocks of v4 space reserved and still
available for allocation. Also, although returns are not frequent, and
the "winners" come from the wait list, these regular allocations (although
not very often) happen from time to t
It has now been about 4 weeks since ARIN-2017-5 was last revised.
Based on the comments received, "more than a /56" is the consensus.
I ask that the AC revise the proposal to this value, so it can be further
considered.
This is the tally so far:
/56 9 votes
Any of these levels are OK - 2 vote
First of all, ALL changes to v4 have been withdrawn from this proposal.
This proposal is ONLY about v6. Currently ALL v6 requires SWIP (/64 or
more) and this is unequal with v4 that has an 8 or more address standard
for SWIP.
I think that drawing the SWIP boundary for IPv6 based upon resident
The main reason I advanced this proposal is because the policy for the
average small user of IPv4 differs greatly from that of that same small
user when they chose to go dual stack and add IPv6 to their network.
The majority of all internet connections for residential and small/medium
business
Unlike IPv4 where most machines has one and only 1 IPv4 address, IPv6
allows easy assignment of addresses, and in fact almost every machine
running any operating system actually has many IPv6 addresses. While the
fixed addresses of SLAAC and DHCP exist, most OS's will use privacy
addresses f
The various comments about this Draft got me to read the things that were
discussed when ARIN-2010-14 changed the SWIP standard from /48 to /64.
Nowhere could I find a specific reason for that change to 6.5.5.1. The
draft only stated the SWIP value was being made /64, without mentioning
that i
Harvesting of customer data is something that has not really been
addressed in the ARIN region, because it has not been an issue for most
customers or ISP's.
Currently it seems that in IPv4 land that 95% to 99% of ISP customers only
have a single IPv4 address. Thus, SWIP in v4 is not done, ex
John,
I think this is the FCC ruling he speaks of, and it does seem to shut down
public disclosures of most of what is contained in SWIP/WHOIS without
customer consent. This has been the rule for regular phone calls for a
long time, called CPNI. Until today I did not realise the FCC extended
Maybe the rule could be SWIP for a /48 or more if the downstream customer
also has an ASN so that they can receive BGP announcements, otherwise
SWIP would not be required.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Mon, 17 Jul 2017, Paul McNary wrote:
Tony
Do you mean BGP
Just a couple of questions regarding the carrots and the sticks for the
ARIN staff:
Other than those who came back to change their initial /35 to a /32, how
many ARIN customers have come back for another allocation of IPv6 space
because they used the first one to the extent the rules require,
The language of "b)" actually makes more sense with a /47:
Each static IPv6 assignment containing a /47 or more addresses, or
subdelegation of any size that will be individually announced, shall be
registered in the WHOIS directory via SWIP or a distributed service which
meets the standards se
For the record, I would be happy if this policy stopped at changing the
100% SWIP requirement for v6 assignments to allowing /56 and smaller to
not have to SWIP. However, if the community agrees, I have no issues with
taking additional actions in this draft, up to and including elimination
of
As someone that once worked with certified zip code matching software
development, I suggest that only a 5 digit code be used for SWIP.
Otherwise you are giving away in that 9 digit zip code enough information
to locate the city block with your customer, or even the exact address.
This is beca
My transit bus example is another example of SWIP difficulty. Very hard
to provide a street address to SWIP a bus when it is mobile 16 hours a
day.
Current policy says SWIP every /64 or more, which is every network in v6.
I did a check here, and in v4, only 1% of customers have more than 8 ip
I started looking at syncing the 2 sections, but I found the sections are
not as much in sync as it was suggested, and my attempts to refer one to
the other were not that successful.
For example, 8.5.4 Initial block appears to refer to the similar section 4
passage 4.2.2, which is much more de
This is a good rewrite of this, and you can count me in favor.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Fri, 21 Jul 2017, Leif Sawyer wrote:
Happy Friday, everybody.
As promised, here is the latest rewrite of the draft policy below, and it will
soon be updated at:
http
Even though the /49, /50 ... /128 is technically covered by the "any size"
language, for all practical purposes /48 or more is all that can be
advertised, as nothing smaller than a /48 is contained in the GRT.
Thus, your perception that it covers only sub-delegations of /48 or more
is correct.
Boy, am I learning from this process. Please let me know if I am not
defining these terms we are discussing below properly:
Allocation: Directly receiving a block of IP addresses from ARIN.
Re-Allocation: Taking part of an Allocation from ARIN, and permitting
another ISP/LIR to use this blo
I simply added the next number in the section labeled "definitions". You
are right that it best fits into 2.5. In that case maybe 2.5's title
should be changed to "Allocate, Assign and Reassignment" and the
definition be added after Allocate and Assign.
Albert Erdmann
Network Administrator
P
/47 or more addresses is intended to be /47, /46 . /1 and not the
reverse. The current language is "/64 or more", and I read that same
phrase as /64, /63 . /1. For comparison, the current IPv4
language is "/29 or more", and that seems clear to mean /29, /28 . /1,
and not the rever
In the case of that 69.0.0.0 block we were talking about, it may not be on
the other side of the earth, but certainly in different states. That
block had the serving site as CT, the parent record as TX, and a note in
that record to send legal process to FL. Quite a trip.
What is the purpose
Im sure glad that /32's of static IPv4 are not subject to SWIP, and that
SWIP does not require GPS info.
If it did, we would be in trouble, as our GPS tracking only updates every
300 seconds or 5 minutes, and we would need a T1 of bandwidth just to keep
the SWIP updated, and for what purpose?
There has been some discussion regarding this question on the PPML, and
since I received different answers regarding this and nothing official
that I can find in the NRPM, I have decided to reach out to someone from
ARIN for an answer.
Currently NRPM 6.5.5.1 requires a static assignment of a /
Of course, I can understand why a PO Box is used, if the place where the
network is set up does not have a street address assigned, and their mail
delivery is therefore required to be sent via a PO Box or otherwise.
I work with a WISP in my area which covers some remote places. About 1/2
of th
I agree that we need to act on THIS draft, and not load up the discussion
with other issues that this draft is not intended to address. The one
question regarding SWIP/WHOIS policy in general I have moved to another
thread since it is unrelated to this draft.
This draft is about changing the
Richard J Letts wrote:
As an example we assign /48's to school districts,
If it is a really small school district, that is unlikely to expand beyond
16 sites, you could give them a /44, otherwise each district should get at
least a /40 or more. A university might need more, or maybe a /40
The first draft of my proposal was very conservative. For v6 I proposed
the two smallest possible subnet values be exempted from SWIP, which was
/60 and /64. I figured that this would be enough for 16 subnets, enough
for IOT and/or guest,wired, and wireless networks on different segments.
Th
I am in favor of the draft, with or without the changes to make it
clearer.
I suggest the following language for clarity:
3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM
that reads "If the downstream recipient of a static assignment of /64 or
more addresses requests
A /47 is larger than a /48, and under the draft must always be registered.
/48's are only registered upon request, or if it is independently routed.
/49 - /64 are only registered upon request. If future routing policy
changes allows these sizes to be independently routed and in fact are so
ro
While the most recent drafts have not dealt with IPv4, in the last round
there was a proposal to require registration upon request of the
downstream customer of their IPv6 assignment.
If we intend to provide that power to require registration for IPv6
customer assignments upon request, in fair
I would not consider an RIR that has NIR units that do not have a bi
directional transfer policy to comply with the policy of ARIN to only
permit transfers to/from those with a bi directional transfer policy.
Thus, I support the statement being added in this draft to make this more
clear.
Al
I was always under the impression that companies that operate in more than
one region usually obtain their number resources from their home region,
and use these worldwide.
I once worked with a company who was based in the Netherlands, but has a
presence all over the world. I was involved in
My gut still tells me that transfers should not take place without a
bidirectional policy. Even then, the other RIR's are very likely seeking
IPv4 resources from ARIN, as opposed to the reverse, simply because ARIN
has under its control more than 1/2 the total space available, because of
the g
I think we got it this time.
I support.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Tue, 22 Aug 2017, ARIN wrote:
The following has been revised:
* Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
Revised text is below and can be found at:
https://www.ari
Since 2.15 recommends a /48 for every end site, any ISP getting a
sub-delegation to use for customers is going to have a /47 or more, which
according to the policy proposal as written will already have a
registration requirement solely by its size.
Thus, I have little reason to worry about any
So based on this policy and the current numbers, which RIR's are covered
by this statement? Is that LACNIC and AFRINIC only?
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Wed, 6 Sep 2017, ARIN wrote:
The following has been revised:
* Draft Policy ARIN-2017-4: Remove Recipro
Now that discussion reveals that "IPv4 Inventory", refers to the total
number of IPv4 addresses that a specific RIR has under its management, and
not the amount of IPv4 addresses remaining for assignment, I will state
the problems I see with the proposal. However, I remain open minded and
am a
The reason that those early class A holders received such a large block
was simply the fact that CIDR did not exist at the time, and therefore
there were only 3 possible values of address blocks you could receive, /8,
/16 and /24. Clearly most of the original class A holders had plans to
(and
Placing ISP/LIR in place of ISP might be the best way to avoid confusion.
As has been pointed out, they are really one and the same.
Otherwise, I think that everything else about the draft is good and
support.
One thing to consider for future discussion is that because of the nature
of IPv6,
While these OS's do use the privacy extensions by default for all outbound
connections, and the addresses are changed every 24 hours or so, from what
I see, they also listen on the MAC address based address as well, and if
they accept inbound connections with their firewall, the MAC based addres
I support with either shall or should. Shall is perferred.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Thu, 28 Sep 2017, Scott Leibrand wrote:
I support this policy proposal with "should" and would also support it with
"shall". I don't think it's a big deal either way.
-S
As the author of the original proposal, I do want to see the main part of
this proposal advance and be passed. Since it has now been pointed out
that the language is currently frozen until the meeting, I note for the
record that I have no problem with the draft as currently written, and
would
I noticed at ARIN40, that "shall" had more votes, and zero "no" votes,
as compared to "should".
Just wondering, what happens/will happen next?
Albert Erdmann
Network Administrator
Paradise On Line Inc.
___
PPML
You are receiving this message because
I support the policy as written, with "shall". I also support with
"should", but would rather have shall.
As for discussion of what ARIN will do if an ISP decides not to follow the
policy, I guess we can ask what ARIN is doing NOW.
Under CURRENT policy (6.5.5.1), a /64 or more of static IPv6
Recommended policy 2017-5 proposes changing the language in 6.5.5.1 from
/64 or more to /47 or more. According to an earlier email, this has been
sent to the ARIN Board for adoption.
The editoral changes in this draft include cleanup of 6.5.5.1, without
noting that the ARIN Board may soon cha
I support this policy.
Giving ISP's/LIR's the ability to add reassignment contacts without
verification from the contacts being added I think was always wrong.
Often, the email added was NOT someone who actually processed abuse
issues, but often was instead someone from purchasing or marketing
Unless the space is legacy, I do not see how space can remain open for 15
years on autopilot, as someone must be paying the ARIN bill.
Even under the original policies, review of use of IPv4 space only comes
up in the context of requesting more space from ARIN. In light of the
marketability o
Private space is a valid use, as this is one of the only ways to ensure
uniqueness. Look at the US Postal Service as an example of this. They
have gobs of mail sorting machines on their class A, none of which is
exposed to the internet. Their public facing services are also in the
lower port
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 fo
In NRPM, I see 3 different IPv4 sizes mentioned. They are the /27
mentioned in section 4, the /24 mentioned in section 8, and the /22
mentioned for the block still available and reserved for IPv6 trans tech.
I say that we set the section 4 standard to /24 same as section 8, as this
allows us
Are there any technical issues related to DNSSEC or otherwise that bind
ASN ranges to specific RIR's. If so, we need to talk about required
measures to deal with this issue.
Other than this, I see no other showstopper to portable ASN's, and would
support.
Albert Erdmann
Network Administrato
I support the changes you have made.
This language looks like it could support most types of community
networks, from the smallest neighbor-to-neighbor links, to larger more
formal networks like the Southeast Florida Library Information Network.
The fact that the Community network definition
I really never considered until this was brought up that community
networks might want to band together to provide backbone connectivity or
otherwise associate with each other. I do not think the Community network
provisions of policy should forbid this.
Based on the discussion around 2017-5,
-- Forwarded message -- Date: Wed, 17 Jan 2018 07:31:05
As for the disease reference, I assume the networks are not real, and only
for the purposes of this discussion.
There are good technical reasons for the example networks to share address
space, if they are not multihomed a
I kinda agree that we should work toward a post free pool world.
Right now, other than the few lucky people who have obtained resources
from the free pool, microallocations under 4.4 or IPv6 deployment under
4.10 are the only IPv4 resources being allocated under section 4 policy.
The majority
I would be opposed to allowing inter regional IPv6 Transfers.
One of the main benefits of IPv6 over IPv4 is the reduction of routing
table size. Allowing inter regional transfers would start the road to
larger routing tables. We allowed a lot of this in IPv4 because of
shortages of addresses.
I can only really think of three:
1) A company is relocating its headquarters from a location served by an
RIR, to another location served by a different RIR, and wants everything
in their new home region.
2) A company decides to buy another company with few assets, but holds a
16 bit ASN in
I agree that IP addresses and ASN's are not associated with each other to
the extent that changes in one, must trigger a change in the other. Thus,
I disagree that an ASN transfer must only occur on "clean" ASNs without
any associated IP networks.
For example, I might have an ASN because I am
I think when the term "number resources" is used, it includes all number
resources, including IPv4, IPv6 and ASN's. References to IPv4 number
resources is more specific and only refers to that resource.
It appears clear to me that the 16 bit ASN is the scarce resource. While
someone might wa
The actual statement proposed does not limit transfers to 16 bit ASN's.
Transfer of IPv6 resources have been discussed before, and most felt it
was not desirable since one of the goals of IPv6 was to reduce aggregation
in routing tables. Allowing transfers would start us down the path of
what
I support.
I think this will go a long way in getting correct POC's in the database
at the start. Currently, whoever is doing the ordering might end up with
their contacts in the database, because that is the only information that
the service provider has. This is how we end up with purchasin
I am against banning attachments, as they can often be useful during
discussions. While google drive and other services can be used by many,
some of us here on this list including myself are barred by network
policies of using or connecting to such services, as they can be used to
leak confide
+1
Keep in mind this goes right along with other things we have done we have
done.
In 2017-5 we changed the IPv6 policy so that only individually routed
blocks had to be SWIP'ed, and normally routed blocks of a /48 or smaller
also do not require SWIP.
The policy all along for IPv4 is /29
I disagree, and think that registration of subassignments should NOT be
required in these cases.
For example, I go to a trade show, and rent a booth. I, representing my
company obtain internet access from the trade show producers (another
company) via wifi. I connect to that wifi using third
+1 on removal of this policy.
I note that the same policy does NOT exist for IPv6, removal is best to
equalize the policies.
I think this policy was originally done to track usage of IPv4 blocks for
the purpose of tracking usage when requesting more addresses. Since there
is no IPv4 free po
While I do not doubt that there might be shell entities that are holding
numbering resources for less than honorable purposes, I was actually more
worried about people forming special purpose LLCs or Corps in order to
hold numbering resources for the purpose of later sale to others. By
forming
They would not have to "sell" the space, but simply sell the company,
whose assets include nothing but the space. In the case of LLC's, a
common manager for multiple LLC's with space might be driving the train,
and no "sale" occurs, but the common manager still manages to control
multiple /22'
I think what ARIN is doing is fine as far as the screening goes, as long
as they are willing to look into fraud when it is found and reported. It
is hard to guess on paper what someone will do with a resource until they
are given a chance to use (or abuse) it.
Albert Erdmann
Network Administr
I agree with this Draft policy.
This is clearly a legacy IPv4 policy. These reallocation requirements
were put in place to document use of IPv4 resources so that you could ask
for more. Without a free pool, this should not be required.
As we move to the future of IPv6, this appears to be an
+1 as to AS transfers.
I have no heartburn regarding this, and the existing unused policy tends
to show that this action is in fact quite rare and likely to be used only
when absolutely needed.
The only thing that I wish to express is that I do not want to ever see
IPv6 transfers, since the
I also have no problem with the Clarification.
I also note that in 2017-5, the registration requirements for IPv6 was
changed to more than a /48. Thus, unless someone is handing out BYOD or
public use IPv6 address blocks larger than this, or with unique routing
applied, that act should never
I agree that we clearly need universal DNSSEC, and ARIN should not take
actions that inhibit universal DNSSEC.
I understand that ARIN has taken actions to try to get the remaining
legacy holders to move to an RSA. While this might be seen as a "carrot"
to try to move these holders to an RSA,
Just so I can get a prospective of how much money was lost for ARIN during
this discussion, can someone please tell me what the current minimum cost
under the current RSA for someone to hold 2 /24's? Five hundred a year
seems to be the stated price, but I am unable to calculate it based on
res
He did not mention an AS number. Being a small player, he might like
myself get away with using one of the AS's in the private network range,
or might just be single homed, in which case he does not need it.
As to spinning off the Legacy holders to another registry, I do not think
this is fai
Forty-one percent is NOT a low number, which is likely why ARIN is trying
hard to get more entities to sign an LRSA/RSAA. So much for thinking this
issue will go away sometime in my lifetime.
However, I suspect most of the /24's reflected in the chart are actually
part of those /8's that we h
1 - 100 of 250 matches
Mail list logo