FCC emergency waiver: Jewish Community Centers Calling Party Number Identification
The FCC granted an emergency temporary waiver to telecommunication carriers serving Jewish Community Centers, allowing access to the Caller-ID (Calling Party Number Identification) normally blocked at the calling party's request (i.e. star-67). Although per call Call-Trace (i.e. star-57) and permanent Trap-and-Trace court orders also report the Caller-ID and other call information, such as ANI to law enforcement; the FCC occasionally granted similar waivers in the past. Obviously this doesn't help with spoofed calling numbers. https://www.fcc.gov/document/fcc-grants-emergency-waiver-help-protect-jewish-community-centers
Re: google ipv6 routes via cogent
On Fri, Mar 3, 2017 at 5:05 PM, Job Snijderswrote: > > There are, of course, corner cases. But in general, single-homed > > people shouldn’t be using BGP. > > There are numerous reasons to use BGP when single-homed: > > - as preparation to multi-home in the (near) future > - ability to quickly change providers > - to use BGP based blackholing features > - to save time on provisioning work (adding new prefixes becomes a > matter of just announcing and updating IRR/RPKI). > - loadbalanacing / loadsharing across multiple links > - ability to use bgp communities for traffic engineering > > In other words, if you have your own IP space, I'd recommend to get your > own ASN and use BGP. I concur with Job. If you are single-homed but care about having proper L3 redundancy (not just VRRP or equivalent), BGP is a must. ARIN has a policy to allow this, but it is not spelled out with an excess of clarity. I suspect it is not often used; see NRPM section 5. -- Jeremy Austin
Re: google ipv6 routes via cogent
On Fri, Mar 03, 2017 at 09:42:04AM -0500, Patrick W. Gilmore wrote: > On Mar 3, 2017, at 7:00 AM, Nick Hilliardwrote: > > Niels Bakker wrote: > >> As I explained in the rest of my email that you conveniently didn't > >> quote, it's so that you can selectively import routes from all your > >> providers in situations where your router cannot handle a full table. > > > > it can also break horribly in situations where the provider is providing > > "transit" but doesn't provide full transit. > > > > OTOH, if you are single-homed, it is highly advisable to accept a > > default, the reason being that most transit providers provide bgp > > communities with "don't advertise to customers" semantics. So if you're > > single-homed and use a full dfz feed without default route, you will not > > have full connectivity to all the routes available from the transit > > provider. Correct. > If you are single-homed, there is no need for BGP at all. That is very strongly worded, and in plenty of cases a false assertion. > And injecting your ASN into the table is probably not terribly useful > to everyone else’s FIB. ASNs don't have anything to do with FIB. > There are, of course, corner cases. But in general, single-homed > people shouldn’t be using BGP. There are numerous reasons to use BGP when single-homed: - as preparation to multi-home in the (near) future - ability to quickly change providers - to use BGP based blackholing features - to save time on provisioning work (adding new prefixes becomes a matter of just announcing and updating IRR/RPKI). - loadbalanacing / loadsharing across multiple links - ability to use bgp communities for traffic engineering In other words, if you have your own IP space, I'd recommend to get your own ASN and use BGP. Kind regards, Job
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith. Routing Table Report 04:00 +10GMT Sat 04 Mar, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 639225 Prefixes after maximum aggregation (per Origin AS): 248678 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 307752 Total ASes present in the Internet Routing Table: 56403 Prefixes per ASN: 11.33 Origin-only ASes present in the Internet Routing Table: 48853 Origin ASes announcing only one prefix: 21709 Transit ASes present in the Internet Routing Table:7550 Transit-only ASes present in the Internet Routing Table:207 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 42 Max AS path prepend of ASN ( 22394) 39 Prefixes from unregistered ASNs in the Routing Table:68 Numnber of instances of unregistered ASNs: 69 Number of 32-bit ASNs allocated by the RIRs: 17548 Number of 32-bit ASNs visible in the Routing Table: 13633 Prefixes from 32-bit ASNs in the Routing Table: 55318 Number of bogon 32-bit ASNs visible in the Routing Table:44 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:397 Number of addresses announced to Internet: 2836585604 Equivalent to 169 /8s, 18 /16s and 220 /24s Percentage of available address space announced: 76.6 Percentage of allocated address space announced: 76.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.5 Total number of prefixes smaller than registry allocations: 213156 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 174750 Total APNIC prefixes after maximum aggregation: 49968 APNIC Deaggregation factor:3.50 Prefixes being announced from the APNIC address blocks: 174086 Unique aggregates announced from the APNIC address blocks:71703 APNIC Region origin ASes present in the Internet Routing Table:7887 APNIC Prefixes per ASN: 22.07 APNIC Region origin ASes announcing only one prefix: 2205 APNIC Region transit ASes present in the Internet Routing Table: 1123 Average APNIC Region AS path length visible:4.5 Max APNIC Region AS path length visible: 41 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2726 Number of APNIC addresses announced to Internet: 760850308 Equivalent to 45 /8s, 89 /16s and 167 /24s APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:194786 Total ARIN prefixes after maximum aggregation:93195 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 197227 Unique aggregates announced from the ARIN address blocks: 90282 ARIN Region origin ASes present in the Internet Routing Table:17817 ARIN Prefixes per ASN:
Re: Qwest/CenturyLink BGP contact?
Someone has reached out -- I'm good to go. Thanks all! On 3/2/17 1:11 PM, Bryan Holloway wrote: Hello all, If someone from Qwest/Centurylink is lurking, could you contact me off-list? You are advertising a /24 out of a recently acquired /16, and I've been unsuccessful reaching anyone. Thanks! - bryan
Re: google ipv6 routes via cogent
On Mar 3, 2017, at 7:00 AM, Nick Hilliardwrote: > > Niels Bakker wrote: >> As I explained in the rest of my email that you conveniently didn't >> quote, it's so that you can selectively import routes from all your >> providers in situations where your router cannot handle a full table. > > it can also break horribly in situations where the provider is providing > "transit" but doesn't provide full transit. > > OTOH, if you are single-homed, it is highly advisable to accept a > default, the reason being that most transit providers provide bgp > communities with "don't advertise to customers" semantics. So if you're > single-homed and use a full dfz feed without default route, you will not > have full connectivity to all the routes available from the transit > provider. If you are single-homed, there is no need for BGP at all. And injecting your ASN into the table is probably not terribly useful to everyone else’s FIB. There are, of course, corner cases. But in general, single-homed people shouldn’t be using BGP. -- TTFN, patrick
Re: google ipv6 routes via cogent
* n...@foobar.org (Nick Hilliard) [Fri 03 Mar 2017, 13:02 CET]: Niels Bakker wrote: As I explained in the rest of my email that you conveniently didn't quote, it's so that you can selectively import routes from all your providers in situations where your router cannot handle a full table. it can also break horribly in situations where the provider is providing "transit" but doesn't provide full transit. You don't need to import them into your border router's FIB. It's always good to be able to change your own routing policy without having to consult your upstream's NOC. -- Niels.
Re: google ipv6 routes via cogent
Niels Bakker wrote: > As I explained in the rest of my email that you conveniently didn't > quote, it's so that you can selectively import routes from all your > providers in situations where your router cannot handle a full table. it can also break horribly in situations where the provider is providing "transit" but doesn't provide full transit. OTOH, if you are single-homed, it is highly advisable to accept a default, the reason being that most transit providers provide bgp communities with "don't advertise to customers" semantics. So if you're single-homed and use a full dfz feed without default route, you will not have full connectivity to all the routes available from the transit provider. Nick
Re: google ipv6 routes via cogent
* how...@leadmon.net (Howard Leadmon) [Fri 03 Mar 2017, 01:06 CET]: On 3/2/2017 2:57 PM, Niels Bakker wrote: You should ask for full routes from all your providers + a default. If you taking full routes from everyone, why would you need a default? If they don't show a route for it, they probably can't reach it. I don't think I have run with a default route external for many years, and so far it hasn't bit me yet.. As I explained in the rest of my email that you conveniently didn't quote, it's so that you can selectively import routes from all your providers in situations where your router cannot handle a full table. -- Niels.