SFR IP Ranges
SFR is the French fixed and mobile operator whose PeeringDB record is filed as SFR Group, points at alticefrance.com, and reports a selective policy with 10 to 20 Tbps of traffic. AS15557 is the number its retail broadband rides on, and the RIPE aut-num is still named LDCOMNET: created on 19 September 2002, held by Societe Francaise Du Radiotelephone - SFR SA and maintained by SFR-MNT, with the customer assignments underneath still sitting behind the older LDCOM-MNT.
- Provider
- SFR
- Primary ASN
- AS15557
- Category
- ISP
- Headquarters
- Paris, France
- Announced IPv4 prefixes
- 146
- Registry
- RIPE
Known IP ranges
These prefixes are currently announced to the global routing table by AS15557 (LDCOMNET Societe Francaise Du Radiotelephone - SFR SA). Prefix sets change over time - use WHOIS Lookup for the authoritative record on any specific address.
93.0.0.0/11
109.0.0.0/11
77.192.0.0/12
86.64.0.0/12
79.80.0.0/12
77.144.0.0/12
78.112.0.0/12
92.88.0.0/13
84.96.0.0/13
77.128.0.0/13
2a02:8400::/25
2a00:6200::/29
2a02:e000::/29 (IPv6)
What does an SFR IP mean in a privacy test?
A visible IP on AS15557 is a French retail line, and the assignment object usually says as much: 77.192.0.0/18 is netname SFR-USER-DATA, described as DSL - End users, under LDCOM-MNT. The reverse hostname is the quickest confirmation, because SFR generates PTRs from the address written backwards, so 92.88.10.20 answers as 20.10.88.92.rev.sfr.net and 86.70.10.20 as 20.10.70.86.rev.sfr.net. Treat that name as the primary signal, since it stays correct when a lookup database is carrying stale ASN data. The delegation is not universal, though: 86.64.10.20, inside the same /12 as the second example, has no reverse nameservers at all, so a missing PTR here is not evidence of anything. One caution before deciding an address is not SFR: sixteen aut-nums are registered to the same SFR organisation in the RIPE database, so plenty of SFR-operated addresses never touch AS15557.
SFR's published routing policy, and a second origin in RADB
SFR publishes no geolocation file. What it does publish, unusually, is its entire traffic-engineering policy inside the registry object: the remarks block of the RIPE aut-num AS15557 is a community list giving each transit its own tag - NTT, DTAG, Telia, Telecom Italia Sparkle, Cogent and Vodafone all appear - plus a tag for every exchange it announces at, among them SFINX, France-IX in Paris, Lyon and Marseille, LINX, AMS-IX, DE-CIX, Equinix Paris, Equinix NY and NINE-IX Paris, each with the port speed and peering address written in. Further tags steer announcements to named content networks one by one, in the form 15557:49x TUNE announce to NETFLIX (AS2906), with equivalents for Cloudflare, Microsoft, Facebook, Google, Amazon, Akamai and Apple. The IRR macro is AS15557:AS-LDCOMNET, peering requests go to peering at sfr.fr, and both the aut-num and PeeringDB point at the same portal: peering.sfr.fr/request-form for the request and peering.sfr.fr/looking-glass for the glass.
The route objects hold a trap. In the RIPE database 77.192.0.0/12 is registered with origin: AS15557 and the description SFR ALTICE France, and 93.0.0.0/11 the same way with the description LDCOM-NET, both under LDCOM-MNT. RADB carries a second object for each of those prefixes with origin: AS198949, the description customer and the maintainer MAINT-AS198949. AS198949 is as-name Radware in the RIPE database, so those objects pre-authorise an SFR aggregate to be announced from a scrubbing network instead of from SFR - meaning a prefix-to-operator check that reads RADB alone can hand you the wrong company entirely. None of these objects carries a geofeed attribute and the assignments name no city, so location has to come from the reverse hostname.
User pools, infrastructure blocks and SFR's other numbers
The netname on the assignment separates customers from kit faster than anything else does. 77.192.0.0/18 is SFR-USER-DATA, descr DSL - End users, maintained by LDCOM-MNT. Sitting inside the same aggregate, 93.20.0.0/20 is N9UF-INFRA, descr Infra misc., and still carries an abuse address at gaoland.net inherited from the Neuf-era estate - infrastructure, not subscribers. Both objects are ASSIGNED PA under the same maintainer, so the status field does not distinguish them; the netname does.
Above the assignment, the brand is not one network. Sixteen aut-nums belong to the same RIPE organisation and they are not interchangeable: AS21502 is ASN-NUMERICABLE, the cable side; AS12566 is SFR-BUSINESS-TEAM; AS8228 and AS12626 are both CEGETEL-AS; AS9003 is ASN-SFR; AS29372 is SFR-NETWORK; AS39079 is SERVICES-IP_SFR; and a run of French public-service fibre concessions hold their own numbers, including AS34860 DSP76, AS3305 ISERE38, AS47206 RENNES-TELECOM-AS, AS43763 HAUT-RHIN-TELECOM-AS, AS49112 ARMORCONNECTIC-AS, AS35632 IRIS64-AS, AS15890 DSP_Martinique_THD and AS208157 DSP_PYRENEES_ATLANTIQUES64. If the question is whether an address is SFR at all, checking the organisation on the aut-num settles it; checking for one ASN does not.
Related tools
Frequently asked questions
Which blocks does SFR announce on AS15557?
The largest are in the fact grid above. For the registered version, the IRR macro AS15557:AS-LDCOMNET is what SFR asks peers to build filters from, and the RIPE route objects carry origin AS15557 with descriptions SFR ALTICE France and LDCOM-NET under the maintainer LDCOM-MNT.
What does a rev.sfr.net hostname tell me?
That the address is one SFR generates a reverse name for, and that the four numbers in front are the address itself written backwards, so 20.10.88.92.rev.sfr.net is 92.88.10.20. It confirms the operator and the fact that this is a retail line. It carries no city, no customer and no service type.
Why does RADB show an SFR prefix originated by AS198949?
AS198949 is as-name Radware in the RIPE database. RADB objects for 77.192.0.0/12 and 93.0.0.0/11 list it as origin with the description customer under MAINT-AS198949, which is the shape of a scrubbing provider pre-authorised to announce a customer prefix during a mitigation. The RIPE objects for the same prefixes carry origin AS15557.
Are all SFR addresses on AS15557?
No. Sixteen aut-nums belong to the same SFR organisation in the RIPE database, among them ASN-NUMERICABLE, SFR-BUSINESS-TEAM, CEGETEL-AS and several regional fibre concessions such as DSP76 and ISERE38. AS15557 is the retail backbone rather than the whole company.
My IP check came back as SFR - should I worry?
A visible IP on AS15557 is a French retail line, and the assignment object usually says as much: 77.192.0.0/18 is netname SFR-USER-DATA, described as DSL - End users, under LDCOM-MNT. The reverse hostname is the quickest confirmation, because SFR generates PTRs from the address written backwards, so 92.88.10.20 answers as 20.10.88.92.rev.sfr.net and 86.70.10.20 as 20.10.70.86.rev.sfr.net. Treat that name as the primary signal, since it stays correct when a lookup database is carrying stale ASN data. The delegation is not universal, though: 86.64.10.20, inside the same /12 as the second example, has no reverse nameservers at all, so a missing PTR here is not evidence of anything. One caution before deciding an address is not SFR: sixteen aut-nums are registered to the same SFR organisation in the RIPE database, so plenty of SFR-operated addresses never touch AS15557.