Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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,

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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,

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21

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

Re: [arin-ppml] Policy Question for ARIN regarding SWIP

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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?

[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Draft Policy ARIN-2017-7: Retire Obsolete Section 4 From the NRPM

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21

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.

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21

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

Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers

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.

Re: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers

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

Re: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers

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

Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation

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,

Re: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation

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

Re: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation

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

[arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation

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

Re: [arin-ppml] Discussion on elimination of SWIP requirements.

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

Re: [arin-ppml] IPv4 SWIP requirements (?)

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

Re: [arin-ppml] IPv4 SWIP requirements (?)

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

Re: [arin-ppml] IPv4 SWIP requirements

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

Re: [arin-ppml] IPv4 SWIP requirements (?)

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.

Re: [arin-ppml] Defining Residential Customers in Policy Manual

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

Re: [arin-ppml] "Residential Customer" by examples

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Discussion on elimination of SWIP requirements.

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

Re: [arin-ppml] Discussion on elimination of SWIP requirements.

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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,

Re: [arin-ppml] Draft Policy ARIN-2017-2: Removal of Community Networks

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

Re: [arin-ppml] IPv4 SWIP requirements (?)

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

Re: [arin-ppml] Draft Policy ARIN-2017-2: Removal of Community Networks

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

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

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

Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

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

[arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

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

Re: [arin-ppml] Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

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

Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers

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

Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers

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

Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers

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

Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

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.

Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

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

Re: [arin-ppml] Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

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:

Re: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

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

Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment

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

Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment

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

Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment

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

Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment

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

Re: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers

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

Re: [arin-ppml] Draft Policy ARIN-2018-4: Clarification on IPv6 Sub-Assignments

+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

Re: [arin-ppml] Draft Policy ARIN-2018-4: Clarification on IPv6 Sub-Assignments

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

Re: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks

-- 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

Re: [arin-ppml] Free-pool allocation policy (Re: Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers)

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

Re: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks

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

Re: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks

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

Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers

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

Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers

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

Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers

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

Re: [arin-ppml] Recommended Draft Policy ARIN-2018-3: Remove Reallocation Requirements for Residential Market Assignments

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

Re: [arin-ppml] ARIN-2018-1: Allow Inter-regional ASN Transfers

+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

Re: [arin-ppml] Beneficial Owners

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

Re: [arin-ppml] Beneficial Owners

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

Re: [arin-ppml] Beneficial Owners

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

Re: [arin-ppml] Draft Policy 2018-1 - Allow Inter-Regional ASN Transfers

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

Re: [arin-ppml] Draft Policy 2018-1 - Allow Inter-Regional ASN Transfers

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

Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon Reassignment

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

Re: [arin-ppml] Requesting moderator intervention

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

Re: [arin-ppml] ARIN discontinuing DNSSEC capability to legacy holders

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

Re: [arin-ppml] ARIN discontinuing DNSSEC capability to legacy holders

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

Re: [arin-ppml] ARIN discontinuing DNSSEC capability to legacy holders

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,

Re: [arin-ppml] ARIN discontinuing DNSSEC capability to legacy holders

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

Re: [arin-ppml] ARIN discontinuing DNSSEC capability to legacy holders

The reason that this issue is so difficult is the funding model of DNS has changed over the years, and the formation of ARIN has never completely addressed that issue. In the beginning days, DNS was in fact a large shared host file, installed on every machine. In effect, the cost of adding

Re: [arin-ppml] Draft Policy ARIN-2018-6: Clarify Reassignment Requirements in 4.2.3.7.1

Looking at this, I am a NO as it is currently written. This section deals with /29 or more IPv4 addresses, or stated another way, 8 or more addresses. Someone who is running such a network in today's IPv4 exhausted world needs to have a means to contact them directly in the event of abuse

Re: [arin-ppml] Draft Policy ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers

My multihoming solution was homegrown, and not a vendor solution. I agree that despite RFC 7084 being issued in November, 2013 there does not yet appear to be a standardized way to multihome more than one provider connection without either using PI space and BGP, or a form of NAT for IPv6

Re: [arin-ppml] Draft Policy ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers

The statement sounds better than before, but I am still opposed to allowing Inter-regional transfers of IPv6 Resources. As pointed out by others, the reasons why IPv4 and ASN transfers that are currently permitted DO NOT exist with IPv6. These are: 1) There is a shortage of 16bit ASN

Re: [arin-ppml] Draft Policy ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers

On Tue, 26 Mar 2019, JORDI PALET MARTINEZ via ARIN-PPML wrote: ???El 26/3/19 23:23, "arin-ppml-boun...@arin.net en nombre de hostmas...@uneedus.com" escribi??: I am opposed. IPv6 policies have been designed from the beginning to limit the growth of the global routing tables.

Re: [arin-ppml] Draft Policy ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers

If that new internet exchange point is now independent of your org, and is in the ARIN region, it should be obtaining its resources under 6.10.1. These allocations are specifically for things like internet exchange points. If they desired independence from the beginning and the ability to

Re: [arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

Most all these problems go away in IPv6. This is because 1) There are plenty of numbers from the original source and 2) There is no "Legacy" space. Therefore, to the best of my knowledge there is no brokering of IPv6 space, nor do we have directed transfer language for IPv6. Why is it that

Re: [arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

How about this for an idea: Change the policy to state once the ipv4 resources have been once directed to a specified recipient after the date of that new policy, those resources are no longer eligible for future transfer to a specified recipient and instead must be returned if they are no

Re: [arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

I was merely proposing making the requirements tougher. The no tax cheat requirement is not in the current policy manual. In addition to the ones that are being caught, because of their attempt to transfer out the numbers to someone else, I venture to guess part of the remainder might be

Re: [arin-ppml] Revised - Draft Policy ARIN-2017-12: POC Notification and Validation Upon Reassignment or Reallocation

+1 on this as well Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 26 Feb 2019, ARIN wrote: The following has been revised: * Draft Policy ARIN-2017-12: POC Notification and Validation Upon Reassignment or Reallocation Revised text is below and can be found at:

Re: [arin-ppml] Revised - Recommended Draft Policy ARIN-2018-2: Clarification to ISP Initial Allocation

+1 on this. On Tue, 26 Feb 2019, ARIN wrote: The following has been revised: * Recommended Draft Policy ARIN-2018-2: Clarification to ISP Initial Allocation Revised text is below and can be found at: https://www.arin.net/policy/proposals/2018_2.html You are encouraged to discuss all Draft

Re: [arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

This proposal is to lower the maximum to a /22. I believe that this is justified to make the waiting list process serve mainly smaller players. While the /22 size will still allow abuse, it clearly does make it harder on the abusers versus the current policy. Changing the waiting list

Re: [arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

Our choices with this Draft Policy: 1) Reject it because it does not completely eliminate the abuse, and allow the current policy (with ALL its abuse) to continue. or 2) Adopt the policy even though not perfect at eliminating ALL the abuse, but does cut back much of it. Adoption of this

Re: [arin-ppml] Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements

I think it is time to start the ball on the other policies. +1 on this. It seems focused on those gathering resources to resell. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 26 Feb 2019, ARIN wrote: On 21 February 2019, the ARIN Advisory Council (AC) accepted

Re: [arin-ppml] Draft Policy ARIN-2019-3: Update 4.10 – IPv6 Deployment Block

+1 on this Since anything smaller than a /24 is unrouteable, this is a positive change. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 26 Feb 2019, ARIN wrote: On 21 February 2019, the ARIN Advisory Council (AC) accepted "ARIN-prop-262:Update 4.10 – IPv6 Deployment

Re: [arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

I think that changing the waiting list limit to a /22 has merit, even when NOT considering those gaming the system and support the proposal. I think of the waiting list process is more for the benefit of the smaller player, and making the limit a /22 is consistent with this. Those that are

  1   2   3   >