- Test - lists.nanog.org

anybody here from earthlink operations?
by Miles Fidelman 28 Sep '17

28 Sep '17

If there's someone here from earthlink operations, can you contact me privately. Thanks! Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra

1 0

Root KSK roll delayed
by Matt Larson 28 Sep '17

28 Sep '17

(Please pardon the repetition if you've seen this message on another list) ICANN has decided to postpone the root KSK roll previously scheduled for 11 October 2017 for at least one quarter. This message gives some background and explanation for that decision. Historically there has been no way to determine which trust anchors DNSSEC validators have configured, making it difficult to assess the potential impact of the root KSK rollover. "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)" (defined in RFC 8145) is a recent protocol extension that allows a validator to report which trust anchors it has configured for a zone to that zone's name servers. The protocol was only finalized in April, 2017, and only the most recent versions of BIND (9.10.5b1 and 9.11.0b3 and later) and Unbound (1.6.4 and later) support it. This protocol was not expected to have sufficient deployment to provide useful information for the first root KSK rollover. However, initial research by Verisign and then by ICANN has found a growing number of validators reporting trust anchor configuration to the root servers. Based on data from six root server addresses, approximately 12,000 unique source IP addresses have sent trust anchor configuration reports so far in September 2017. The number reporting is growing and now approaches 1400 unique addresses per day. Significantly, approximately 5% of the total validators and about 6%-8% on any given day report only KSK-2010, the root zone KSK currently signing the root's DNSKEY RRset. These validators would not resolve correctly after the planned root KSK roll. There are various reasons a validator might report only KSK-2010. One reason is an old configuration with a statically configured trust anchor (e.g., BIND's "trusted-key" statement). ICANN has always known that a small percentage of validators would not be ready for the rollover because they had manually configured their trust anchor, and that operators of those validators would need to take action when the root KSK rollover happened. Another reason is a failure to automatically update the trust anchor using the RFC 5011 automated update protocol because of a software defect, operator error or other reason. Based on our research and preliminary investigation, we also believe it is possible that some operators believe that they are ready for the rollover because they configured their validator to use RFC 5011 automated updates, but will not trust KSK-2017 when the rollover happens due to configuration issues or software defects. Given the relatively high percentage of validators with just KSK-2010, ICANN believes it is important to better understand the reasons before proceeding with the root KSK roll. We will soon be publishing the list of resolvers reporting only KSK-2010 and will ask for the operational community's help in identifying, diagnosing and correcting these systems. Throughout the project we have emphasized that the root KSK is being rolled under normal operational conditions and have proceeded cautiously and without haste. The decision to postpone was taken in that spirit of caution because there is no operational pressure to proceed given our continued confidence in the security of KSK-2010. We appreciate the community's understanding and we look forward to your assistance in gathering the information necessary to move forward with the root KSK roll. Matt -- Matt Larson, VP of Research ICANN Office of the CTO

1 0

New TRANSLANT cable - US/VA to ES
by Jay R. Ashworth 28 Sep '17

28 Sep '17

Microsoft, Facebook, Telxius. 160TB, presumably each way, but no technical detail in this piece: https://interestingengineering.com/microsoft-and-facebook-just-laid-a-6600-… Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

4 3

1and1 DNS contact
by Feldman, Mark 28 Sep '17

28 Sep '17

If there's anyone from 1and1 (specifically, someone involved with apps-1and1.com) please contact me off list. We're running across a DNS resolution issue from some places on our network and would like to discuss. Thanks. Mark Comcast T&P Core Network Services

1 0

Information about the national test of the Emergency Alert System
by Sean Donelan 28 Sep '17

28 Sep '17

> And your upstream(s) to work. And their upstream(s) to work. etc. If 90% > of the stations in the EAS web are down you may end up with nothing > working. 6% of TV stations are operating in Puerto Rico 15% of radio stations are operating in Puerto Rico Nationally, there are about 28,000 cable systems, radio and television stations. This test will not use the FEMA primary entry point system, so its only a partial test of the national EAS. Today's national test of the Emergency Alert System will be the same as the 2016 national test. It is a partial test of the EAS, using the FEMA IPAWS system over the internet (i.e. Akamai and Cloudfront are used as CDNs) to the distribute the emergency test message. Cable, radio and TV stations need a working Internet connection as well as radio receivers and transmitters for IPAWS and EAS. Although the national test was scheduled back in July, its still a good test opportunity to see how the internet and EAS works in Puerto Rico and the U.S. VI with so much damage to the infrastructure. The one minute national test should not intefere with disaster recovery efforts in PR or USVI. For more information: https://www.fema.gov/news-release/2017/09/19/mandatory-nationwide-test-emer… https://www.fcc.gov/document/nationwide-emergency-alert-system-test-planned…

3 2

Google DNS64 misconfigured?
by Joel Whitehouse 28 Sep '17

28 Sep '17

I had an ipv6-only lab environment cease being able to browse much of the internet on Monday. Tracked the issue down to google's public DNS64 service; the following queries should return DNS64 responses from the 64:9bff::/96 prefix, however, I'm getting 0 DNS64 answers from dig on both their servers for the last 60 hours: dig @2001:4860:4860::64 ipv4only.arpa AAAA dig @2001:4860:4860::6464 ipv4only.arpa AAAA DNS works fine, just not DNS64. A forum topic [0] suggests this behavior might be intermittent but no official response from google there. Is google's public DNS64 down for anyone else? [0] https://groups.google.com/d/topic/public-dns-discuss/dD_lSPfqXHA/discussion -- Joel Whitehouse

3 2

Re: DHCPv6-PD -> Lack of route injection in RFC
by Baldur Norddahl 27 Sep '17

27 Sep '17

This method is lacking because you might have several routers eg. using VRRP and the backup router will not learn anything from a relay on the primary. Den 22. sep. 2017 14.02 skrev "Steve Teusch" <steve.teusch(a)rtr.guru>: I am running into venders that do not support injection of a delegated route when operating as a DHCPv6 relay (or server for that matter). Brocade supports this, but I am not finding this as part of any of the RFC's. This is to deliver home ISP service, so it is very important or return packets won't go to the client unless the route is manually added as a routing protocol is not an option. There should be a MUST activity for this somewhere. Anyone know what gives?

8 9

Anyone else having issues with AS209 in the Northwest?
by Christopher E. Brown 26 Sep '17

26 Sep '17

We have no direct peerings with 209, but a large percentage of traffic flowing through 4 different peers and into 209 in the Seattle area has serious issues. -- ------------------------------------------------------------------------ Christopher E. Brown <chris.brown(a)acsalaska.net> desk (907) 550-8393 cell (907) 632-8492 IP Engineer - ACS ------------------------------------------------------------------------

1 0

Major European Continental Long Haul Conduit
by Rod Beck 26 Sep '17

26 Sep '17

I would to tap the collective wisdom of NANOG. What are the major conduit systems in Europe? I know when MFN Europe went bankrupt, everybody jumped in and bought their fiber. So I list GTT/Hibernia, EUNetworks, Zayo, and who else rids this conduit system. And who rides the Level3 conduit and what the other key systems. And yes, I am thinking of the terrestrial routes connecting the European racetrack: Amsterdam, Frankfurt, Paris, and Milan. Regards, Roderick. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com<http://www.unitedcablecompany.com> 85 Király utca, 1077 Budapest rod.beck(a)unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png]

1 0

IPv6 migration steps for mid-scale isp
by Fredrik Sallinen 26 Sep '17

26 Sep '17

Hello, Recently we have decided to start IPv6 migration in our network. We have ~1K BNGs and connecting our customers to network using PPPoE. I'd be interested in hearing from the technical community about their experiences and recommendations on this process. I'm wondering: Shall I go for IPv6-only deployment or dual stack? Where to start with IPv6? (core, edge or ...) What are the best practices for ISPs? What are the costs and return on investment? How to identify address CPE and legacy application issues? Fredrik

14 20