- NANOG - lists.nanog.org

Bogon ASN Filter Policy
by Job Snijders 08 Jun '16

08 Jun '16

Dear fellow network operators, In July 2016, NTT Communications' Global IP Network AS2914 will deploy a new routing policy to block Bogon ASNs from its view of the default-free zone. This notification is provided as a courtesy to the network community at large. After the Bogon ASN filter policy has been deployed, AS 2914 will not accept route announcements from any eBGP neighbor which contains a Bogon ASN anywhere in the AS_PATH or its atomic aggregate attribute. The reasoning behind this policy is twofold: - Private or Reserved ASNs have no place in the public DFZ. Barring these from the DFZ helps improve accountability and dampen accidental exposure of internal routing artifacts. - All AS2914 devices support 4-byte ASNs. Any occurrence of "23456" in the DFZ is a either a misconfiguration or software issue. We are undertaking this effort to improve the quality of routing data as part of the global ecosystem. This should improve the security posture and provide additional certainty [1] to those undertaking network troubleshooting. Bogon ASNs are currently defined as following: 0 # Reserved RFC7607 23456 # AS_TRANS RFC6793 64496-64511 # Reserved for use in docs and code RFC5398 64512-65534 # Reserved for Private Use RFC6996 65535 # Reserved RFC7300 65536-65551 # Reserved for use in docs and code RFC5398 65552-131071 # Reserved 4200000000-4294967294 # Reserved for Private Use RFC6996 4294967295 # Reserved RFC7300 A current overview of what are considered Bogon ASNs is maintained at NTT's Routing Policies page [2]. The IANA Autonomous System Number Registry [3] is closely tracked and the NTT Bogon ASN definitions are updated accordingly. We encourage network operators to consider deploying similar policies. Configuration examples for various platforms can be found here [4]. NTT staff is monitoring current occurrences of Bogon ASNs in the routing system and reaching out to impacted parties on a weekly basis. Kind regards, Job Contact persons: Job Snijders <job(a)ntt.net>, Jared Mauch <jmauch(a)us.ntt.net>, NTT Communications NOC <noc(a)ntt.net> References: [1]: https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 [2]: http://www.us.ntt.net/support/policy/routing.cfm#bogon [3]: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml [4]: http://as2914.net/bogon_asns/configuration_examples.txt

8 7

Re: Netflix VPN detection - actual engineer needed
by Baldur Norddahl 08 Jun '16

08 Jun '16

On 2016-06-08 17:20, Javier J wrote: > > Maybe I missed the start of this conversation but why are we talking > about blocking Netflix? > By blocking the netflix.com IPv6 prefix your browser will automatically fall back to IPv4 because it is using the Happy Eyeballs algorithm.

1 0

Traffic engineering and peering for CDNs
by Graham Johnston 08 Jun '16

08 Jun '16

Lately I have been putting in some effort to maximize our IX connections by trying to work with the top 5-ish list of ASNs that still send us traffic via a paid transit connection despite the fact that we are both present on the same IX(s). In one case I missed the fact that one ASN wasn't using the IXs route-servers, that's on me for not spotting that one. Even with proper IX peering in place though it seems like some CDNs are better at using the IX connections than others. ASN 15169 for instance does an excellent job sending more than 99.99% of traffic via the IX connection; thank you. While others only seem to manage to send 60 - 80% of traffic via the IX. What I am not understanding about the respective CDN's network wherein they don't send traffic to me through a consistent path? Is the content coming from widely different places and rather than transport it across their own network from a remote site they would rather hot-potato it out a local transit connection? Are their transit costs so low that they don't care about using an IX connection over transit unlike a small operator like me? Is this just a non-obvious issue wherein they maybe just can't originate enough of the traffic near the IX and therefore don't make use of the IX connection, again a hot-potato phenomenon? Secondly can someone explain to me why some CDNs want a gigabit or two of traffic to be exchanged between our respective networks before they would peer with me via a public IX? I totally get those kinds of thresholds before engaging in a private interconnect but I don't understand the reluctance with regard to a public IX, that they are already established at. Is it again just a simple case of bandwidth economics that operate at a different scale than I can comprehend? I'm hoping the community can shed some light on this for me as I'm trying to avoid grilling the operators that are working with me as I don't expect those front line individuals to necessarily have a full view of the factors at play. Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong(a)westmancom.com<mailto:johnstong@westmancom.com> P think green; don't print this email.

8 7

IPv6 is better than ipv4
by Ca By 07 Jun '16

07 Jun '16

https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-wh… Wherein akamai explains a detailed study showing ipv6 is "well over 10%" faster than ipv4 on mobile, and they reference corroborating studies from Linkedin and Facebook. Fair to ask your business 1) does mobile performance matter 2) are you taking advantage of this 10% page load speedup that ipv6 provides?

17 28

Re: Netflix VPN detection - actual engineer needed
by Baldur Norddahl 07 Jun '16

07 Jun '16

> And they could easily redirect HE IPv6 addresses to a IPv4 only > service. This would satify both the content providers and the > customers. It's not like there tunneled traffic is IPv6 only as > there has to be a IPv4 endpoint for the tunnel. > > You can't argue that HE is too small to do this for as they are > targeting HE tunnels. > > Mark And while we wait for Netflix to do that, you could also turn off ipv6 on your Netflix watching device as a quick fix. Most smart tv do not support it to start with. It is a bit surprising that your browser would choose the ipv6 path via tunnel over the more direct ipv4 path. Anyway, you could blackhole the Netflix ipv6 prefix to force the situation. Or you could get your own /48 prefix and announce via BGP. Might not be free but comes with other advantages and has some coolness factor. Or turn off the tunnel while you watch Netflix. Lots of options for "can do" people. Yes we all hate geo ip solutions but this particular Netflix issue is not a big thing in the grand scheme of things. Regards Baldur

2 1

Re: Netflix VPN detection - actual engineer needed
by Mark Felder 07 Jun '16

07 Jun '16

On Mon, Jun 6, 2016, at 13:09, Brandon Jackson wrote: > Looking up your tunnels block in ARIN will only show HE's Info. > > Using HE's rwhois http://rwhois.he.net/whois.php > > Shows the information provided by the tunnel user at time of signup or as > modified in account settings. > Ahh, correct. This way is showing it for me. I should have known to use their rwhois. -- Mark Felder feld(a)feld.me

11 11

any way to deal with google's captcha for whole /21 v4?
by Dmitry Sherman 06 Jun '16

06 Jun '16

Hello dear Nanog group, Any suggestions how to deal with Google captcha for whole /21 ipv4 newly acquired block? Every IP from the prefix getting blocked by Captcha which never resolves. Thanks in advance. — Dmitry Sherman Interhost Networks Ltd dmitry(a)interhost.net office: 972-74-7029881 mobile: 972-54-3181182 http://www.interhost.co.il

2 1

ISP License in the USA?
by Lorell Hathcock 06 Jun '16

06 Jun '16

NANOG: Our owner has hired a consultant who insists that we should have an ISP license to operate in the United States. (Like they have in other countries like Germany and in Africa where he has extensive personal experience.) I am asking him to tell me which license we should have because I don't know of a license that we are required to have to route IP traffic to end customers. I am familiar with CLEC status filed with our state. But it is not a requirement to pass traffic. He is suggesting COALS with which I am completely unfamiliar. Can anyone tell me if there is a Texas state and/or USA Federal license for a small operator to pass IP traffic from the internet to end users (commercial and/or residential). I am aware that there are some CALEA requirements of ISPs that seem to kick in once a CALEA request is made, but is that different from a license. Thanks, Lorell Hathcock

18 25

rfc 1812 third party address on traceroute
by Randy Bush 06 Jun '16

06 Jun '16

rfc1812 says 4.3.2.4 ICMP Message Source Address Except where this document specifies otherwise, the IP source address in an ICMP message originated by the router MUST be one of the IP addresses associated with the physical interface over which the ICMP message is transmitted. If the interface has no IP addresses associated with it, the router's router-id (see Section [5.2.5]) is used instead. some folk have interpreted this to mean that, if a router R has three interfaces .-----------------. | | | B |--------- D S ---------| A R | | C |--------- (toward S) | | `-----------------' if the source of a traceroute from S toward D with TTL to expire on R, and R's FIB wants to exit via C to get back to S (yes, virginia, the internet is highly asymmetric), the source address of the time exceeded message should be C. of course, simpletons such as i would desire the source of the time exceeded message to be A. after all, this is the interface to which i sent the icmp with the TTL to expire. ras's preso, https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_… page 10 illustrates this issue with rfc1812 cursory research and talking with C & J seem to indicate that they do what i want not what some folk have interpreted 1812 to mean. at least on some models. is anyone seeing the dreaded rfc1812 behavior in a citable fashion? how common is it? randy

10 19

ERPS/G.8032 interoperability
by Denis Fondras 05 Jun '16

05 Jun '16

Hi all, Is there any study on ERPS/G.8032 interoperability between different equipment manufacturer ? Denis

1 0