- NZNOG - lists.nznog.org

Re: [nznog] Citylink IX communication
by Richard Naylor 01 Mar '17

01 Mar '17

At 11:18 p.m. 27/02/2017, Dylan Hall wrote: >Disclaimer: I worked for CityLink a while back so feel free to >consider the following biased or well informed as you see fit :) > >I think one aspect of this discussion that is often overlooked is >who participates in the peering exchanges. It's not just a handful >of large ISP's and content providers. > >Take a look at: > ><http://nzix.net/ape-peers.html>http://nzix.net/ape-peers.html >http://nzix.net/wix-peers.html > >We have a huge range of participants: universities, schools, >government, data centres, finance, researchers, broadcasters, etc. >Very few of these organisations operate networks as their core business. > >If it's so important to convince them all to opt-in to the change >what are we doing to explain why they should make that change? >Pointing at an RFC and yelling loudly hardly seems likely to be >accepted as a convincing argument outside of the networking community. Similar Disclaimer: I worked for CityLink a while back so feel free to consider the following biased or well informed as you see fit :) The original name WIX was "Wellington Information Exchange" back in 1996 to 1998. In 1997 (roughly) there was trial work done with Fore ATM switches because there was significant interest in " video" peering and "E1-peering", between Govt agencies. Of course VoIP-peering does a better job but has made less progress. WIX may lack the traffic volumes and number of carriers/ISPs but WIX is a more interesting exchange in terms of economic development in a community. Of course it does by-pass "service providers" in doing a lot of that. Some of the applications that (in theory) run include page ads for newspapers where the bank can update the interest rate in the ad for each edition of a newspaper. The ads used to cross town via cycle courier. WIX enabled that to be via FTP, without traffic charges. ( and couriers). So many of the WIX peers were on private AS numbers and often had someone else manage a simple peering router. This B2B peering is why there was a focus on having as many regional IXs as possible.

1 0

IANA IPv4 Recovered Address Space registry updated
by Paula Wang 01 Mar '17

01 Mar '17

Hi, An update has been made to the IANA IPv4 Recovered Address Space registry according to the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA (https://www.icann.org/resources/pages/allocation-ipv4-post-exhaustion-2012-…) The list of allocations can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space/ Kind regards, Paula Wang IANA Services Specialist PTI

1 0

Citylink IX communication
by Tim Hoffman 26 Feb '17

26 Feb '17

Greetings, Given the importance of Citylink's IX services in the community, I feel that it is valuable to notify this communication from them to the entire list. I would note that they are explicitly stating in this communication they will not ever forcibly require consistent behavior. I would note that this is in direct violation of RFC7947; *2.2.2.1. Route Server AS_PATH Management* * As a route server does not participate in the process of forwarding* * data between client routers, and because modification of the AS_PATH* * attribute could affect the route server client BGP Decision Process,* * the route server SHOULD NOT prepend its own AS number to the AS_PATH* * segment nor modify the AS_PATH segment in any other way.* I would like to encourage (publicly) that Citylink implement this consistently, rather than in a haphazard way that varies customer by customer. Consistency is the key to supporting the NZ internet effectively *(Note, RFC7947 doesn't say "do this when your customer can be bothered")*. Additionally, I would like to encourage Citylink to communicate with the NZNOG community when publishing updates that could have an operational impact on the internet in NZ as a whole. Cheers, Tim ####### FOREWARDED MESSAGE BELOW ####### Dear REDACTED CityLink would like to inform you of some exciting NZIX developments that concern your existing ExchangeNET connection(s). We’re introducing some changes to the way we operate the NZIX route servers in order to improve our compliance with recent proposed standards (RFC7947 and RFC7948), and to minimise the disruption caused by routine administrative changes going forward. *Background* CityLink provides two route servers at each of the NZIX exchanges - currently Auckland (APE), Hamilton (HIX), Wellington (WIX), Christchurch (CHIX) and Dunedin (DPE). The route servers facilitate multilateral interconnection between the participants at each exchange by simplifying the BGP configuration and admin overhead otherwise needed to exchange routing information between multiple eBGP speakers. The NZIX route servers have traditionally prepended the exchange’s Autonomous System (AS) number to the AS path of the prefixes they advertise back out to peers. *What is changing?* A number of ExchangeNET customers have expressed a preference that the NZIX route servers no longer prepend the exchange AS number to the AS path of advertisements sent to them. This preference is consistent with recent proposed standards (RFC7947 and RFC7948), and is the recommended best current practice for Internet exchange route server operation. However, in order to put this change into effect, ExchangeNET customers who peer with the NZIX route servers may need to make a (potentially disruptive) change to their existing BGP configuration. While CityLink would prefer all ExchangeNET customers peering with the NZIX route servers to support this alignment with best current practice, we recognise that the timing to implement such changes may differ based on your individual business needs. Therefore, we have decided to implement the changes on a per-participant basis, and we invite those ExchangeNET customers who would like to “opt-in” to the changes (that is, for the NZIX route servers to no longer prepend the exchange AS number to the AS path of the advertisements sent to them), to contact us. We will endeavor to accommodate requests for configuration changes to be made at times convenient for each ExchangeNET customer, commencing from *13th March 2017* onwards. *Note:* We will *not* be changing the configuration of any existing sessions without that participant’s agreement. *What are the implications of the change?* · ExchangeNET customers who peer with the NZIX route servers will see the AS path for prefixes received shortened by one hop (the exchange AS number). This may alter the current choice of best path for those prefixes. · If you had been using the presence of an exchange AS in the AS path to influence your organisation’s routing policy, you may need to amend your configuration in order to achieve your routing policy objectives. It may not be quite so obvious that a given route has been learnt from a particular NZIX exchange point going forward. · Your router may need to be configured with its equivalent of *no bgp enforce-first-as* to restore its BGP session(s) with the NZIX route servers after the change is made. *I’d like to “opt-in” to the change. What do I need to do?* If you’d like us to remove the exchange AS number from the AS path of the advertisements you receive from the NZIX route servers, please email us at *peering(a)citylink.co.nz <peering(a)citylink.co.nz>* with your AS number, the contact details for the person(s) from your organisation that will be involved in making the changes, and an initial indication of when you’d like to implement the change (if known). Changes will only be implemented at a mutually-agreed time to minimise any disruption, commencing from *13th March 2017* onwards. *I’d prefer not to “opt-in” to the change right now. Do I need to do anything?* If you’d prefer that the NZIX route servers continue prepending the exchange AS number to the AS path of advertisements sent to you, you don’t need to take any action right now. However, we would appreciate a return email confirming the contact details for the most suitable person(s) from your organisation whom we should engage with on these matters going forward. *I’d prefer not to “opt-in” to the change at all. Will I be encouraged to eventually?* It is hoped that over time all ExchangeNET customers will choose to “opt-in” and thus support CityLink’s efforts to align the NZIX exchanges with best current practices, to the benefit of the wider NZ Internet community. *What will be the “default” configuration for new ExchangeNET customers?* Going forward, all new BGP sessions configured on the NZIX route servers will conform to the recommend best current practice (that is, the route servers will *not* prepend the exchange AS number to the AS path of prefixes sent to peers). *Is anything else changing?* Yes! The method by which configuration changes have historically been “pushed” to the NZIX route servers has necessitated a “hard reset” of the BGP session(s) with all existing peers. Although the two route servers at each exchange are reloaded independently (ensuring that each peer has an established session with at least one NZIX route server at all times), the overheads associated with performing the hard reset are higher than they need to be. In order to minimise the impact of routine administrative changes going forward, we are changing the way in which configuration changes are pushed to the route servers. Note that changes will continue to be applied to each route server independently, however, thereby ensuring optimal availability for NZIX. *I have a question about these changes. Who should I contact?* Please email us at *peering(a)citylink.co.nz <peering(a)citylink.co.nz>* in the first instance. We’ll be happy to help! Kind Regards, [image: CityLink Ltd] <http://www.citylink.co.nz/> *Toll Free* 0800 424 895 Level 6, 25 Cambridge Terrace *www.citylink.co.nz <http://www.citylink.co.nz/>* Wellington 6011 This mail message contains information that is confidential and which may be subject to legal privilege. If you are not the intended recipient, you must not use, distribute or copy this message. If you have received this message in error, please notify the sender immediately and erase this mail and its attachments.

7 10

Re: [nznog] Xtra and SPF
by Glen Eustace 20 Feb '17

20 Feb '17

> On 8/02/2017, at 1:15 PM, Criggie <criggie(a)criggie.org.nz> wrote: > > Its not really an answer, but SPF is doing what its told. Agreed. > > So either you have to convince Xtra's mail to disable their rejections > (unlikely) or you have to get something into the customer's SPF record > to permit your hosts to send. The domains with the hard fail SPFs are not my customers so I have no control over them at all. The issue is people emailing from those domains to domains we do host and they are getting the bounce and blaming us. (perhaps rightly so, but this has only become an issue in the last week and even then for only 2 customers) > Dirty hack that won't work much is to IPv6-enable your mail relay. There > seem to be fewer restrictions on that side, at least google is a little > more accepting. Already fully IPv6 enabled. So it looks like I need to go back and have another look at SRS. It would seem that either few organisations hosting email are ‘relaying’ like we do or have already implemented SRS. If that is the case, I’d be interested in knowing whether SRS creates its own set of problems.

12 11

NZNOG 2017 Videos
by Dave Mill 20 Feb '17

20 Feb '17

Hi all We have made the talks available from NZNOG 2017. Day 1 : https://www.youtube.com/playlist?list=PLeAkos2dldO5EmOe5zPbSuQzXoq4s Jeos Day 2 : https://www.youtube.com/playlist?list=PLeAkos2dldO5vjrg6vS0rYEPIvRs8 naAA Thanks to our A/V guys for doing the work behind this. Cheers Dave

2 1

Upcoming APNIC elections
by Tim Hoffman 20 Feb '17

20 Feb '17

Hi New Zealand internet community! I wanted to remind everyone that the APNIC elections <https://www.apnic.net/community/participate/elections/ec/ec-election-proces…> are coming up, with voting <https://www.apnic.net/community/participate/elections/ec/voting/> now closing in 6 days (3pm Monday, 27 February 2017). It's important that we all get involved in the democratic process that APNIC has and vote - those elected will determine policies that impact us all (for instance around IP address transfers and justification of IP space as we ramp down IPv4). Specifically, I wanted to highlight two candidates from the list of nominees <https://2017.apricot.net/elections/nominations/> that you may want to consider voting for to represent us. Both have had ties to the New Zealand internet community for over a decade, understand the challenges we face, and I believe would represent our needs well. Jon Brewer <https://2017.apricot.net/elections/nominations/jonathan-brewer/> is well known to our community. Wellington based, he founded Araneo and ran this company for some years, then since selling Araneo to TeamTalk has focused on helping developing communities (particularly in the pacific islands) establish better connectivity locally and to the world. *Gaurab Raj Upadhaya* <https://2017.apricot.net/elections/nominations/gaurab-raj-upadhaya/> has had involvement in many countries whose internet infrastructures have been developing over the past decade. He has strong ties to the networking community in New Zealand; these began in the early FX days. Starting his career in Nepal, he has experienced challenges greater than those we face in New Zealand around being a remote internet community connected to a US-centric internet first hand. He now leads the network organization at Limelight. *Don't forget to vote!* Cheers Tim -- Tim Hoffman | Twitter, Inc. 1355 Market St. | San Francisco, CA | 94103

2 1

Drinks - Auckland CBD 14/2
by Fraser McGlinn 13 Feb '17

13 Feb '17

Hi Guys, I'll be over in NZ (Auckland) early next week with the boss and thought a few beers were in order to catch up with people that we may not have seen in a while as well as to meet more of the NZNOG folk. We'll be putting on a few drinks at The Bluestone Room (9-11 Durham Ln, Auckland) on the 14th Feb from about 5:30pm, feel free to come down and join us for a few beers. Cheers, Fraser Drinks - Auckland CBD 14/2 Fraser McGlinn - Senior Network Operations Officer Web: www.anycast.com.au<http://www.anycast.com.au/> Peering: AS58511<https://www.peeringdb.com/asn/58511> Main Office: +61356224600 Level 1, 5/15 Phoenix Street Warragul, Victoria 3820, Australia [cid:image001.png(a)01D272FA.31833AC0] This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it.

7 7

AWS Sydney
by Jed Laundry 08 Feb '17

08 Feb '17

Hey, Is anyone else noticing high packet loss to AWS Sydney this morning? PING ap-southeast-2.console.aws.amazon.com (54.240.195.68) 56(84) bytes of data. 64 bytes from 54.240.195.68 (54.240.195.68): icmp_seq=12 ttl=240 time=40.4 ms 64 bytes from 54.240.195.68 (54.240.195.68): icmp_seq=17 ttl=240 time=39.6 ms 64 bytes from 54.240.195.68 (54.240.195.68): icmp_seq=20 ttl=240 time=40.7 ms 64 bytes from 54.240.195.68 (54.240.195.68): icmp_seq=32 ttl=240 time=161 ms 64 bytes from 54.240.195.68 (54.240.195.68): icmp_seq=34 ttl=240 time=40.2 ms 64 bytes from 54.240.195.68 (54.240.195.68): icmp_seq=39 ttl=240 time=294 ms 64 bytes from 54.240.195.68 (54.240.195.68): icmp_seq=41 ttl=240 time=40.7 ms 64 bytes from 54.240.195.68 (54.240.195.68): icmp_seq=47 ttl=240 time=40.4 ms 64 bytes from 54.240.195.68 (54.240.195.68): icmp_seq=54 ttl=240 time=65.5 ms Thanks, Jed.

10 9

Re: [nznog] Xtra and SPF
by Glen Eustace 07 Feb '17

07 Feb '17

> On 8/02/2017, at 1:03 PM, Jasper Bryant-Greene <jbg(a)rf.net.nz> wrote: > > SRS is the solution to this and is a standard, available on most mail systems. SPF is a good idea according to most of the internet, and is very widely implemented, so I suggest just getting with the times and fixing your mail relay to rewrite sender addresses according to the SRS standard rather than claiming to send mail for domains it's not authorized to do so for. I have found several articles saying that SRS is, like SPF, basically broken in that it doesn’t handle any situation where multiple relays are involved (not prepared to comment on whether that is right or not), hence my reluctance at this stage to using it. I agree that in principal SPF is a good idea but it breaks mailing lists, forwarding and relays. It has been my believe that using ~all (soft fail) is better than -all (hard fail) so that various anti-spam systems can use the soft fail as a contributing weighting, along with other things to determine what should be done with a message and to not rely on just the SPF.

1 0

NZIX / AKL-IX feedback
by Chris Browning 26 Jan '17

26 Jan '17

Hi All, With NZIX being a Not-for-profit that is overseen by a committee of its members, there a number of idea's bouncing around the of things that we could/should do with NZIX and the membership funds coming in. The NZIX committee is really interested in feedback on how we are going and where we should be heading to ensure that we steer the exchanges in the direction that best serves our members and the New Zealand Internet. NZIX has made a short survey to attempt to get some feedback on what we should be focusing on which can be found here https://www.surveymonkey.com/r/NZIX2017. Cheers Chris

1 0