It seems Aptum has decided they will no longer SWIP any of their
address space. I've been trying to get a SWIP for a /48 that we
were allocated in 2017, but they refuse. And I also see they have
pro-actively gone in and un-SWIPed both our /24s.
Since you are ignoring my tickets about this, maybe somebody from
Aptum would care to speak up in public and defend this "policy?"
--lyndon
I can’t speak for aptum, but I’m curious as to why this is important to you? I’m not trying to discount this at all, just curious why this matters in the internet of 2023.
I went through a couple years back and removed all of our mostly outdated SWIP data and replaced it with generic information. But I run an eyeballs network and I don’t remember the last time we allocated something shorter than a /28 to a customer.
I can think of a couple reasons it might be good for the swip to still reflect the actual customer. But most of the ones I can think of don’t apply as much anymore. About the only things I can think about which may matter has to do with reverse dns delegation if the parent block is smaller than a /16 and maybe having specific contact or address information in specific circumstances.
Mainly I’m asking to update my personal knowledge of how these records are used anymore.
Matt Harris
VP OF INFRASTRUCTURE
Follow us on LinkedIn!
816-256-5446
The only real reason I can think that you would want space SWIPed to you is if you are trying to get an allocation of your own and trying to prove you have existing space to renumber out of.
In 25 years of working for ISPs I don’t think I’ve ever worked for one that SWIPed IP space of any size to an end user and I don’t think I’ve ever seen a request. Mostly because no one wants to put a list of customers out in the public domain.
In the early 2000s I worked for a local provider who had a competing Muni who was using whois and rDNS to target all of the local provider’s customers. I overheard two of their sales guys while eating at a local restaurant telling each other how they could use that info for leads and which tech was helping them get it. I went back to the office that afternoon and sanitized our rDNS to put a stop to that.
-richey
The SWIP stuff I cleaned up included stuff from the pre-2000 period when the internet was a kinder, gentler place. NAT also wasn’t a thing so if a company had 1000 PCs you allocated them multiple /24s. So SWIP was a thing. And yes, it was how you justified more space.
Once NAT happened and we switched to mostly handing customers /32s and started recovering larger allocations, the SWIP also stopped and the bitrot started to set in. About that time I became less involved due to being pulled other directions so no one was maintaining the SWIP. When someone started whining about whois data being outdated probably 5+ years ago I just went in and removed the swips.
An interesting datapoint is that last I checked our original pair of /24s that were provided to us by our original tier 1 provider in 1994 is still listing us in the whois data even though we haven’t used that carrier or the address space for 20+ years now.
SWIP’ing or delegating address space is a requirement of the contract signed with ARIN when the addresses were granted. If you route a /24 to a customer and you are not keeping WHOIS updated, my understanding is that you are in violation of that agreement which might put your ability to use those addresses in the future in jeopardy.
Forrest Christian (List Account) writes:
I can't speak for aptum, but I'm curious as to why this is important to
you? I'm not trying to discount this at all, just curious why this
matters in the internet of 2023.
Two main reasons.
1) We are trying to set up internal peering with AWS, and they use
the rwhois info to validate that the addresses we want to route to
them are actually assigned to us.
2) We (Hushmail) often have to deal with overly zealous mail firewall
administrators (typically, state gov't medically-focused departments)
who have a bad habit of outright blocking any mail from a non-US
source. But we also get this from general mail firewall appliance
vendors who maintain their own blacklist. Being able to point them
at valid rwhois data to verify this mail is coming from a legitimate
email provider is (or has been) our first step in getting our mail
relays removed from those lists.
(1) is directly impacting our business right now. (2) will rear its
head before long -- we usually run into those cases every three to
four months.
But the last time I looked, it's also ARIN's policy to require ISPs
(which Aptum is) to SWIP addresses in order to justify future requests
for address space. I'm curious what will happen the next time they
ask for additional ip6 allocations. Or maybe they have no growth
plans?
--lyndon
If you believe they're committing fraud with respect to their
community responsibilities vis a vis SWIP, and refusing to SWIP even
upon customer request looks fraudish to me, ARIN has a reporting
process:
https://account.arin.net/public/fraud
It won't quickly fix your practical problem but it might give you some
moral satisfaction.
Regards,
Bill Herrin
There is an inherent assumption here that the address space in question was obtained after ARIN existed and that the space is covered by a signed contract. But since that isn’t likely the situation at aptum, I’ll agree with your point.
I also could have sworn that ARIN used to have an option where you could provide the data to ARIN but it wouldn’t appear in the public rwhois data. But for whatever reason I can’t find any evidence of this, so it might just be faulty memory of the last 30 years of policy changes.
So as another list member pointed out, they MAY have an obligation to do the swip, depends on the details of the parent address allocation origin and what their contractual relationship with the registrar is. Assuming modern direct allocations from ARIN, this is almost certainly the case.
Just a couple of workaround thoughts:
For the immediate concern will aptum provide you a LoA and would Amazon accept this instead of the rwhois entries?
I’m also wondering if this might be a “no one that has got the request actually has a clue how to resolve your issues” issue. I’ve seen situations where companies don’t know how to respond to a request outside the most common requests they get. Sometimes some enterprising employee will also totally misunderstand your request and do stupid things like do exactly opposite what you want them to do like remove correct information in an effort to “fix the incorrect info”. And sometimes employees convey “we don’t have a clue” as “we don’t do that”.
Have you tried any other backchannels other than NANOG? Like peeringdb contacts (if you have access) or maybe through linkedin or something like that? Or threaten to change providers at the earliest possible moment?
There are ISPs that swip, all allocations except those which are
'residential' (see arin / ripe rules about this, privacy related)...
My home internet connection when I worked for uunet had swip data the
company automatically added, as it did with all customers. (in fact
that swip still exists, for <reasons>)
They can SWIP or Publish the information in “a directory services system which meets the standards set forth in section 3.2.” ISPs are Required to publish each individual network delegation of a /29 or more addresses Identifying the holder,
other than they can Redact the personal information for individual residential customers.
So an ISP Don’t have to SWIP as long as they do the second thing, But Either way each individual customer network
larger than the size threshold and their provided contacts are to appear in WHOIS.
This is important in order to
provide accurate NOC / Technical and Abuse contact to the community for the purposes Of validating legitimate
technical contacts for a variety of reasons, contacting users about connectivity issues, and being able to
submit abuse reports expeditiously to All Involved contacts (Abuse reports and technical issues are not to be sent
Solely to a network’s upstream provider).
If the info. is not published then they are not fulfilling their obligations and expected conduct as a network service provider
(they have not subdelegated those numbers and retain them for their own use).
I wonder. Has there ever been a case where ARIN took action for a violation of this policy?
Richey
…
Yes and no. ARIN won't assign additional addresses (including address
transfers) until the ISP is in compliance with the SWIP/rwhois policy.
When there are complaints on file, they'll be particularly diligent
about checking that compliance. They won't revoke addresses for not
complying with the SWIP policy, but when they carefully check your
compliance (often due to complaints) they may find other faults for
which revocation is justified. That latter bit has happened more than
once.
Regards,
Bill Herrin
This is important in order to
provide accurate NOC / Technical and Abuse contact to the community for the purposes Of validating legitimate
technical contacts for a variety of reasons, contacting users about connectivity issues, and being able to
submit abuse reports expeditiously to All Involved contacts (Abuse reports and technical issues are not to be sent
Solely to a network’s upstream provider).
But…
Arin doesn’t seem to require the contact information in most cases.
Absent a specific customer request, all a provider seems to have to do to comply is to say either “this block is assigned to a residential sub” or “this block is assigned to company X”. Only upon a request from the sub or in the case of a reallocation does the info need to contain poc info.
Forrest Christian (List Account) writes:
I'm also wondering if this might be a "no one that has got the request
actually has a clue how to resolve your issues" issue. I've seen
situations where companies don't know how to respond to a request outside
the most common requests they get. Sometimes some enterprising employee
will also totally misunderstand your request and do stupid things like do
exactly opposite what you want them to do like remove correct information
in an effort to "fix the incorrect info". And sometimes employees convey
"we don't have a clue" as "we don't do that".
I long ago resigned myself to the reality that the first response
to any ticket will be a pointless, irrelevant, and mostly content
free reply from somebody who didn't even make an effort to actually
read the ticket. It generally takes three rounds before the ticket
gets to somebody with a clue. This applies across the board to
pretty much every vendor/supplier these days 
Have you tried any other backchannels other than NANOG? Like peeringdb
contacts (if you have access) or maybe through linkedin or something like
that?
Someone from Aptum did get in touch and says they will apply the
mallet 'o understanding to the appropriate people inside estruxture.
I don't think estruxture were the actual problem, but if I get a
fix to the problem, that's good enough. For now.
Or threaten to change providers at the earliest possible moment?
Our current contract is up in about two years. Based on what we've
seen out of estruxture/Aptum over the last couple of years, I'm
certainly going to investigate alternatives. Bell has much more
modern colo < two blocks from our office. Now would be prime time
to start planning for a move.
--lyndon
When I worked for a local/regional ISP in the late 90s/early 00s, we initially SWIP’d assignments for business customers and did generic assignments for things like dial-up address pools or NAT front-end ranges for residential customers, but provided more detailed information for business customers. Around 1998/1999 we switched from doing SWIPs to running our own rwhois server. Because we had good documentation, our IP block requests to ARIN were generally pretty painless.
Thank you
jms
For the past 20 years, I've been using PTR records as the basis for
patterns that are then classified according to various criteria:
assigment type (static/dynamic/mixed) and various other things like
NATs, infra, resnets, shared and dedicated webhosts, and so forth.
Turns out it's a pretty useful way to decide whether to accept mail
from an end user node or reject an ad click from a datacenter, among
myriad other uses.
Part of the process involves trying to determine whether generic names
that don't indicate assignment type are static or dynamically
assigned, and one helpful clue is rwhois that accurately reflects the
size and hopefully registrant of the block with that naming.
Of course, with WHOIS gutted, and rwhois servers that don't work or are
nonexistent, my job here is complicated enough. It really helps to be
able to know what I'm looking at. So YMMV but I find accurate, detailed
rwhois AND PTR records extremely useful, as do the folks who license our
dataset, which at last look covers around 97.4% of IPv4 PTRs (for fun,
take a look at a Hilbert map I did of our coverage, and the following
example PNGs showing our overall coverage per /8 and the breakdown of
which IPs in which /8 have PTRs and how they are classified).
Hilbert map:
enemieslist: coverage map
Coverage by /8:
http://enemieslist.com/coverage20230429.png
Classification breakdown by /8:
http://enemieslist.com/coverageclasses20230506.png
Basically, you may not care but there are a lot of companies and
researchers who very much do.
For another example of why this matters, we were customers of a large
business class cable company from mid-2007 through early 2013, and as
we were doing some small-scale hosting, we asked for and got a /27
with custom PTRs assigned. They're still there. Oddly enough, I asked
hostmaster@$BIGCABLECO today to remove them again (I do it every few
years out of a triumph of hope over experience that is never requited).
Maybe it will today, I don't know. But if you ever see abusive traffic
from a block that has been assigned to a NC community college whose
IPs have PTRs in either of the following domains, it wasn't us.
Steve
