Operators generally want to do the right thing.  But at the same time, there's 
no real leverage over a paying customer who is breaking no laws and just never 
paid ARIN's bills and has out-of-date contact info.  You can tell them to go 
talk to ARIN.  But you can't disco them or turn off your BGP session.  So 
whether it's an unregistered ASN or an ASN clearly marked "BAD! NO!", we 
generally find the ISP is unproductively stuck in the middle.


________________________________
From: [email protected] <[email protected]> on behalf of Mike 
Hammett <[email protected]>
Sent: Monday, April 4, 2016 9:53 PM
Cc: [email protected]
Subject: Re: [arin-ppml] 2-byte ASN policy

Would operators take hijacking an ASN issued to someone more seriously than 
squatting on an ASN issued to no one?

I'd assume no one cares about the risk to the squatter.



-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

[http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/ICSIL>[http://www.ics-il.com/images/googleicon.png]<https://plus.google.com/+IntelligentComputingSolutionsDeKalb>[http://www.ics-il.com/images/linkedinicon.png]<https://www.linkedin.com/company/intelligent-computing-solutions>[http://www.ics-il.com/images/twittericon.png]<https://twitter.com/ICSIL>

Midwest Internet Exchange
http://www.midwest-ix.com

[http://www.ics-il.com/images/fbicon.png]<https://www.facebook.com/mdwestix>[http://www.ics-il.com/images/linkedinicon.png]<https://www.linkedin.com/company/midwest-internet-exchange>[http://www.ics-il.com/images/twittericon.png]<https://twitter.com/mdwestix>
________________________________
From: "David Huberman" <[email protected]>
To: [email protected]
Sent: Monday, April 4, 2016 3:56:34 PM
Subject: Re: [arin-ppml] 2-byte ASN policy


Chris's excellent question jogs my brain to ask a related-but-different 
question:


ARIN has traditionally had a large number of AS numbers (almost all 2-byte) in 
the "hold" bucket. These are ASNs which have been revoked for years due to 
non-payment and separation from the RSA.  But they're still found in the DFZ.


Can't ARIN ask requestors who say they need 2-bytes if they'd be willing to 
accept a 2-byte ASN that may have route announcements present in the DFZ, and 
due to circumstances blah blah blah?  It boils down to "we have 2-byte ASNs, 
but they're not quite as clean as one might expect - is that ok?", because I'm 
pretty sure the answer will always be "HECK YEAH!"    ASNs aren't quite like IP 
addresses in this context.  There's no conflict I know of unless the new 
registrants tries to directly exchange routes with the old registrant, which is 
mathematically highly improbable.


________________________________
From: [email protected] <[email protected]> on behalf of 
Chris Woodfield <[email protected]>
Sent: Monday, April 4, 2016 4:30 PM
To: Adam Thompson
Cc: [email protected]
Subject: Re: [arin-ppml] 2-byte ASN policy

Do we have information on how many 2-byte ASNs get returned, compared to the 
rate of requests for them? Is there a surplus?

On Apr 3, 2016, at 11:36 AM, Adam Thompson 
<[email protected]<mailto:[email protected]>> wrote:

IMO, 2-byte ASNs should simply be retired and not reallocated. "Solving the 
technical problem", as described in your email, is actually ensuring the 
perpetuation of a different technical problem.
It's the same sort of thing as the IPv4 vs IPv6 --transition, but this time 
ARIN has an opportunity to at least avoid being part of the problem, even if it 
can't really be part of the "solution".
Let's please not prolong this problem, too... even in central Canada, known for 
a paucity of upstream carriers, it's now commercially feasible to work around 
the 2-byte technical limitations.

-Adam


On April 3, 2016 12:59:37 PM CDT, Andrew Dul 
<[email protected]<mailto:[email protected]>> wrote:

Hello,

I am starting a new thread in PPML, as a follow up to the ARIN
suggestion and consultation which recently started regarding creating a
2-byte ASN waiting list.

The original suggestion is here:

https://www.arin.net/participate/acsp/suggestions/2016-04.html

ARIN opened a consultation on this suggestion on the arin-consult
mailing-list.  This thread starts here for those who are not subscribed
to arin-consult.

http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html

http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html

As the thread evolved it has been suggested that this issue should be
resolved via the policy development process rather than through a
suggestion.

There are a number of questions that have been raised by this thread.  I
am copying them here to continue the discussion on PPML.

===

Working problem statement: ARIN will receive 2-byte ASNs as  returns
over time, and these ASNs have perceived or additional value to
organizations compared to 4-byte ASNs.  How should ARIN allocate these
2-byte ASNs?

===

Should they be given to the next requester, regardless of technical need
for a 2-byte ASN? (What are the technical qualifications we should use
if there is a specific technical need?  e.g. provides transit to more
than 1 ASN?)

If there is really a technical need for 2-byte ASNs, shouldn't we
attempt to build an inventory of 2-byte ASNs?

Should returns be held in reserve?

Should ARIN hold them for some period of
  time
before reallocating them?

Should they be put up for auction to  qualified organizations?

Should they be given to the 1st organization  on a wait-list for 2-byte
ASNs?

Would an organization looking for a 2-byte ASN have the option to
receive a 4-byte ASN in the interim?  If they did would they have to
return it?

Should the waiting list be closed to organizations that already have a
2-byte ASNs?

I and the AC would appreciate your comments on these questions so that
we can start to build a draft policy that best matches with what the
community would like to see implemented by ARIN.

Thanks,
Andrew



________________________________

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

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List 
([email protected]<mailto:[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.

Reply via email to