Re: IPv6 prefix from T-Mobile USA used but not announced in BGP (2607:7700::/32)
On Wed, 27 Apr 2016, Baptiste Jonglez wrote: While doing statistics on the participants of a public DHT, I was surprised to see some IP addresses that are not present in the DFZ: I believe those are used by T-mobile's 464XLAT (RFC 6877) implementation. Recent Android on T-mobile is IPv6-only and has no ability to connect to raw IPv4 addresses. T-mobile's DNS servers are only asked by these devices to translate hostnames to IPv6 addresses. If they can't find an IPv6 address, they will look up the IPv4 address for a hostname, and pack it into the bottom 32 bits of an IPv6 address that routes to a IPv6-to-IPv4 NAT device. 2607:7700:0:25::4e00:605b 4e00:605b -> 78.0.96.91 -- Aaron
Re: IPv6 prefix from T-Mobile USA used but not announced in BGP (2607:7700::/32)
On Wed, 27 Apr 2016, Baptiste Jonglez wrote: So, if this is basically DNS64/NAT64, these IP addresses should not be seen as source or destination address outside of T-Mobile's network, and are not attached to the interface of any device. Based on http://dan.drown.org/android/clat/, it looks like it may be possible for an IPv4-only application to connect to raw IPv4 addresses through a IPv4-to-IPv6 NAT service on the Android device itself, which then is transported over IPv6 to T-mobile's IPv6-to-IPv4 NAT device. Skimming https://github.com/savoirfairelinux/opendht/blob/master/src/dht.cpp, my guess is that new peers find your IPv4 address:port (on T-mobile's IPv6-to-IPv4 NAT device) in the DHT and contact you, which somehow doesn't get correctly translated back to IPv4 before it makes it to your application, so you are seeing the untranslated IPv6 address. Replying to the new peer on the T-mobile-internal IPv6 address should still work as long as you stay on T-mobile's network but are of limited use otherwise. -- Aaron
Re: DNS caches that support partitioning ?
On Sat, 18 Aug 2012, Patrick W. Gilmore wrote: IMHO, if Google losses a datacenter and all users are stuck waiting for a long TTL to run out, that is Very Bad. In fact, I would call even 2.5 minutes (average of 5 min TTL) Very Bad. I'm impressed they are comfortable with a 300 second TTL. Google is very aggressive about reducing user-visible latency, of which they cite DNS as a significant contributing factor. They may be choosing to strike a different balance of faster when everything is working correctly vs faster to recover when something breaks. -- Aaron
Akamai charges for IPv6 support?
Is it normal to bill for IPv6 service as a separate product? I was surprised to hear from from my Akamai rep they they do: Hi Aaron, We can add the IPV6 service to the contract at an additional cost of $XXX/month. Please let me know if you would like to go ahead with the service and I can create the contract and send it for your review. I've been working on adding IPv6 support to my current project on my own time, and am now ready to enable it. But as soon as there is a recurring cost associated with IPv6 support, I need to be able to justify it. And I'm afraid that I can't currently explain a benefit of enabling IPv6 for our users. I'll likely end up not doing so while we're still an Akamai customer. It's Akamai's network, so it's their choice. But big players adding friction to enabling IPv6 certainly doesn't seem in everyone's best interests in the long-term. -- Aaron
RE: Akamai charges for IPv6 support?
On Mon, 18 Aug 2014, Mehmet Akcin wrote: What did they say when you asked them(Akamai)? I quoted their response in my mail; sorry if that wasn't clear. They offered to enable IPv6 service for a non-trivial monthly recurring fee, which they offered to send me a revised contract to include. I would imagine ipv6 to be included in price not an additional fee. I was surprised to find that wasn't the case. -- Aaron
Re: Akamai charges for IPv6 support?
On Mon, 18 Aug 2014, Noam Freedman wrote: I'll make sure someone follows up on your ticket. To help accelerate overall IPv6 adoption, we stopped charging for new conversions to IPv6 over a year ago. Probably just some misinformation in the sales force from the old policy... Oh, I hadn't expected that to be stale information. That's good to hear. Feel free to reach out directly to me if you end up needing more help. Hopefully that won't be necessary, but thanks! -- Aaron
Re: Dial Up Solutions
On Sun, 18 Oct 2015, Clayton Zekelman wrote: I didn't think Asterisk had modem DSP and RAS code?! Huh? I was surprised to find IAXmodem (http://iaxmodem.sourceforge.net/), which is "a software modem written in C that uses an IAX channel (commonly provided by an Asterisk PBX system) instead of a traditional phone line and uses a DSP library instead of DSP hardware chipsets." It appears to be limited to 14.4k due to patent issues and handles faxes only, but its existence suggests writing a software-only data modem should be possible. -- Aaron At 09:31 PM 17/10/2015, Dovid Bender wrote: You can use Asterisk. All you need a digium/sangom T1/E1 card and a box. --Original Message-- From: Will Duquette Sender: NANOG To: nanog@nanog.org ReplyTo: wi...@staff.gwi.net Subject: Dial Up Solutions Sent: Oct 16, 2015 15:28 Does anyone have any suggestions on equipment for our ISP that is still supporting dial up customers? At the moment we are running 3Com Total Control 1000's but are running out of spare parts as we have failures. Given that this gear is so old trying to source spare parts is proving to be difficult. We do have access to an Cisco AS5200 but are looking for maybe a SIP based solution that could possibly run on our VM farm? Has anyone heard of anything like that or does it even exist? What kind of gear are you running if you still are supporting dial up customers?
Re: BGP Traffic Engineering question
On Tue, 10 Nov 2009, Drew Weaver wrote: If you have several transit providers connected to your network and much of your traffic is generally directed by the "BGP tiebreaker" (i.e. lowest IP address) is there a way, without specifying on a per-prefix basis to prefer the "tie breaker winner" slightly less often? Assuming Cisco, set "bgp always-compare-med", "bgp deterministic-med", and in your route-map in, "set origin igp" and "set metric X". You can then vary X as you see fit as an alternate tie-breaker. As long as you never set the metric the same on two different paths for the same prefix, it'll never fall back to router-id. Depending on the transit provider, you can often match bgp communities to determine which are customer routes or the region where the announcement was heard, which you can then use as a tie-breaker when setting the metric. Barring that, as-path access-lists matching specific path fragments can do the same thing, but seems to take more work to maintain as relationships change over time. -- Aaron
Re: isprime DOS in progress
On Wed, 21 Jan 2009, Phil Rosenthal wrote: This attack has been ongoing on 66.230.128.15/66.230.160.1 for about 24 hours now, and we are receiving roughly 5Gbit of attack packets from roughly 750,000 hosts. I'm only receiving NS queries for "." from spoofed 66.230.128.15 and 66.230.160.1 via above.net (of my three transit providers) and none from peering. This usually indicates a single source, such as one rooted machine on non-BCP38 net spewing most of a gigabit. Given the attack is still in progress, I can't really say much more publicly, but suffice to say, we're working on the situation. Have you had any luck tracking back the source of the spoofed packets?If me talking to above.net sounds useful, let me know. -- Aaron
Re: Youtube Geolocation
On Thu, 21 Apr 2011, Dan White wrote: We're experiencing very poor quality with You Tube, and it appears we're subject to a bad entry within a geolocation database somewhere. I'm not sure about Youtube, but Google seems to do some some clever but annoying things with correlating requests going through a recursive nameserver with the location of those browsers. If a bunch of browsers in Atlanta use a recursive nameserver in Los Angeles, Google after a while seems to start offering that nameserver Google server IPs close to Atlanta to give back to its clients. This internet draft might be part of a related work: http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-00 When we attempt to view videos, the contact comes back to us from IPs like: I ran into this problem while running a Tor exit node (which seems to terribly screw with this mechanism) and played with it for a while. I found my nameserver being offered Google server IPs all over the globe; one week it would be London, the next week Germany, then New York, etc. My problem was first solved by changing my browser to use recursive nameservers in a different /24 (changing the last octet didn't seem to help) and later by changing Tor itself to use Google's own 8.8.8.8 nameservers, which caused the problem to go away for other clients of my nameserver. Try using nameservers on a different /24 and see if the problem goes away. -- Aaron
