ftr - Fast TraceRoute

WHOIS Enhancement Proposal for ftr

Problem Statement

Currently, when ASN lookups fail (IP not announced in BGP), we lose valuable routing context. This particularly affects:

• Internet Exchange Points (IXPs) like Equinix peering facilities
• Private peering arrangements
• Infrastructure IPs not publicly announced

Example: 206.223.116.16 (pat1.sjc.yahoo.com)

• Has reverse DNS indicating Yahoo infrastructure
• No ASN data available (not in BGP)
• WHOIS reveals: Owned by Equinix (206.223.116.0/24)
• This is likely a peering point at an Equinix facility

Proposed Solution

Add WHOIS lookup as a fallback enrichment source when ASN lookups fail, with aggressive caching.

Benefits

1. Better IXP Detection: Identify Internet Exchange Points (Equinix, AMS-IX, etc.)
2. Improved Segment Classification: IXP/peering points should be classified as TRANSIT
3. Network Ownership Context: Show organization even when AS not announced
4. Complete Path Understanding: Fill gaps in routing visualization

Implementation Design

1. WHOIS Service

// New service alongside AsN, Rdns, etc.
pub struct WhoisService {
    cache: Arc<Mutex<WhoisCache>>,
    client: WhoisClient,
}

pub struct WhoisInfo {
    pub cidr: String,           // e.g., "206.223.116.0/24"
    pub organization: String,    // e.g., "Equinix, Inc."
    pub netrange: String,        // e.g., "206.223.116.0 - 206.223.116.255"
}

2. Caching Strategy

Aggressive caching is justified because:

• IP ownership changes extremely rarely (years/decades)
• WHOIS data is per netblock, not per IP
• WHOIS servers often rate-limit queries

Cache design:

struct WhoisCache {
    // Key: CIDR block (e.g., "206.223.116.0/24")
    // Value: (WhoisInfo, expiry_time)
    entries: HashMap<String, (WhoisInfo, Instant)>,
    
    // TTL: Very long (30+ days reasonable)
    default_ttl: Duration::from_secs(30 * 24 * 60 * 60),
}

3. Integration Points

Enrichment flow:

1. Try ASN lookup (existing)
2. If ASN fails but IP is public:
   • Check WHOIS cache for containing CIDR
   • If miss, perform WHOIS lookup
   • Cache result by CIDR block
3. Use organization info for classification

Segment classification enhancement:

// Known IXP organizations
const IXP_ORGS: &[&str] = &[
    "Equinix",
    "AMS-IX", 
    "LINX",
    "DE-CIX",
    // ... more IXPs
];

// If no ASN but WHOIS shows IXP org -> TRANSIT
if whois_info.is_ixp() {
    SegmentType::Transit
}

Display Enhancement

Current output:

12 [ISP   ] pat1.sjc.yahoo.com (206.223.116.16) 10.972 ms

Enhanced output with WHOIS:

12 [TRANSIT] pat1.sjc.yahoo.com (206.223.116.16) 10.972 ms [Equinix IXP]

JSON enhancement:

{
  "ttl": 12,
  "segment": "TRANSIT",
  "address": "206.223.116.16",
  "hostname": "pat1.sjc.yahoo.com",
  "asn_info": null,
  "whois_info": {
    "organization": "Equinix, Inc.",
    "cidr": "206.223.116.0/24",
    "is_ixp": true
  },
  "rtt_ms": 10.972
}

WHOIS Client Options

1. Direct WHOIS Protocol (port 43)
   • Pro: No dependencies
   • Con: Need to handle different server formats
2. RDAP (REST-based successor to WHOIS)
   • Pro: JSON responses, standardized
   • Con: Not all RIRs fully support it yet
3. Hybrid Approach
   • Try RDAP first (cleaner)
   • Fall back to WHOIS if needed

Performance Considerations

• WHOIS lookups only for IPs without ASN data (minority of hops)
• Aggressive caching minimizes lookups
• Could pre-populate cache with common IXP ranges
• Async/parallel lookups maintain performance

Privacy & Rate Limiting

• Respect WHOIS server rate limits
• Consider adding config option to disable WHOIS lookups
• Cache sharing between traces reduces queries

Future Enhancements

1. IXP Database: Maintain list of known IXP IP ranges
2. Peering Detection: Identify direct peering relationships
3. Organization Mapping: Map org names to well-known entities
4. AS Relationship Data: Combine with BGP relationship data

Backwards Compatibility

• New field whois_info is optional in JSON
• Existing code continues to work
• Feature can be disabled via config flag

Example Implementation Priority

1. Phase 1: Basic WHOIS lookup and caching
2. Phase 2: IXP detection and TRANSIT classification
3. Phase 3: RDAP support
4. Phase 4: Advanced relationship mapping

This enhancement would provide valuable routing context currently missing from traceroute tools, especially for understanding Internet infrastructure and peering arrangements.