October 2019 - connect-wg - mailman.ripe.net

Fwd: Re: BEREC consultation: contribution
by Steve Nash 13 Nov '19

13 Nov '19

I have only partially absorbed all aspects of the BEREC document and EU Article61, but my impression is of some important missing elements. In particular, I have not noticed references to co-habitation of multiple NTP in one customer site. The subject of resilience seems missing. BEREC has given us a simple model on which to comment, with three levels of NTP. Rather than defining what an NTP must always be, I prefer to consider what a customer needs from the NTP regardless of its logical location. Given that we are RIPE, and given the absence of any bidirectional Public Data Communication Network other than the Internet, I focus my comments accordingly. Summary Whatever the point of delivery of the Network connection, there must be clear signalling of whether or not the provision of Network connection is functional. For Internet Access the NTP must indicate the status of its connection to the Internet. The form of the indication is considered next for each of the BEREC logical Termination Points. *BEREC connection point C:* (Where the NTP has a routing function or NAT, IP aware) The NTP must indicate via its customer port, using IETF standard routing protocol, what connections it is offering /{list of minimum customer selectable protocols?}/. It must withdraw those routing announcements as quickly as the standard allows in the event that its peer router in the network becomes unavailable. *BEREC connection point B:* (Where the connection is provided at a modem port, Ethernet or WiFi) The network must provide signalling of its status to the user. The user must be provided with: * visibility of the adjacent router(s) by routing protocol announcements from the operators router(s). The list of offered routing protocols being a required part of the service description. * the IP address delegated by the operator for the CPE, manually or by DHCP. * the permanence of the IP address delegation (Static or Dynamic) * the IP address of the adjacent router(s) in the provider's network, to enable security filtering *BEREC connection point A:* (Where the connection is by wired, optical or wireless Ethernet) The Network must offer DHCP for the customer's delegated address, and the address of the available Network router. The Network may offer IP routing protocols, as for connection point B. The physical Signal must be withdrawn at the physical layer when the Network is otherwise unable to communicate loss of routes ( for comparison consider removal of dial tone). *Other Requirements:* 1/ In cases B and C, user-configuration of the characteristics of the user port must be supported. Including Local MAC address, Local IP address, Local default router, Local routing protocol, as applicable. 2/ It must be contractually clear whether an Internet Connection service at an NTP is fully open, or in some way restricted.A fully open Internet Connection will have a public IP address capable of end to end communication with any other public Internet address on the same version of IP. This would facilitate the customer in supporting an Internet Server, if they so choose. Restrictions that make the connection less than a fully open Internet connection must be disclosed in the documentation of the connection service, and include: * Network Address Translation, either in the network (CGN) or on supplied NTP. * Blocking of access to some Internet addresses (as has sometimes been the case for open DNS resolvers). 3/ Power Supply resilience for network devices becomes increasing important. Consideration should be given to regulation of common low power battery backup supply connection for all NTP. Rationale Most homes in the EU have more than one Network by which to access the Internet, commonly one fixed and one or more mobile. The NTP of each Network must allow for the existence of others and must enable the customer to program decisions about which Network to use. Automated resilience of Internet connectivity becomes increasingly important as: * home working becomes more prevalent * critical devices such as medical appliances and alarm systems are connected in the home via the Internet Therefore resilience for Internet connectivity must be considered in regulation with respect to both Network selection and power supply resilience, as follows. *Network selection:* On the PSTN the existence of Dial-tone has been the indication of availability at the NTP. A home can easily have more than one PSTN NTP, and more than one fixed line connection to the Internet in addition to mobile. Therefore, customer owned equipment must have the opportunity to be able to directly determine, in an automated fashion, whether or not connectivity via each Internet Connection Provider is functional. Methods are dependent on the chosen logical Network Termination Point and are proposed in the Summary above. *Power supply resilience:* Logical termination equipment (e.g. modem) may be required for some physical access media. If power is not supplied from the network then the customer's domestic supply may be used. In the latter case the regulator must give consideration to backup supply standardisation. The proliferation of individual AC to DC power converters and the need for Inverters to get back to AC supply levels from battery backup is not energy efficient. Standardisation of low power DC supply to NTP devices would reduce electrical wastage and could reduce the number of manufactured components required where devices are permanently powered with DC. Steve Nash Writing my personal opinions, with the Sponsorship of NETSCOUT. On 10/10/2019 17:52, Marco Hogewoning wrote: > Dear colleagues, > > Earlier this week, BEREC (Body of European Regulators for Electronic Communications) announced a public consultation on their draft guidelines for interpreting the “network termination point (NTP)”. These guidelines have been designed in accordance with Article 61(7) of the European Electronic Communications Code to provide national regulatory authorities (NRAs) with guidance on how to interpret the EU directives and implement them in their national legislation. > > This consultation is open to the public. While the RIPE NCC has no particular position on this topic, we think it is important for the community to consider the impact of these guidelines. They could impact not only our members’ operations, but the RIPE NCC’s engagement strategy on a number of topics such as IPv6 and IoT security. > > We invite the Connect Working Group to discuss the proposed guidelines and, should it reach a rough consensus as determined by the chairs, the RIPE NCC is willing to submit that opinion as a response on behalf of the RIPE community. As we see pros and cons to either alternative, failure to reach consensus will mean we will not respond to this consultation on behalf of the RIPE community, but would instead encourage individual members to provide their own responses. > > I’ll provide a brief description of the problem space and the potential impact below, but I recommend reading the draft guidelines as they are posted on the BEREC website: > https://berec.europa.eu/eng/document_register/subject_matter/berec/regulato… > > Please note that while BEREC’s deadline is 21 November, we would need a few days to process and file the formal response and we kindly request the working group to respect close of business on 15 November as its internal deadline to reach consensus. > > Key Issues > > One of the key questions laid out in the document is whether or not the CPE or modem is part of the NTP. EU Regulation 2015/2120 states with regard to Internet access services in article 3(1): > >> “End-users shall have the right to access and distribute information and content, use and provide applications and services, and use terminal equipment of their choice […]” > The 2016 BEREC Guidelines on net neutrality rules (paragraphs 26 and 27) provide further guidance on the implementation and state: > >> “In considering whether end-users may use the terminal equipment of their choice, NRAs should assess whether an ISP provides equipment for its subscribers and restricts the end-users’ ability to replace that equipment with their own equipment, i.e. whether it provides ‘obligatory equipment’. >> >> Moreover, NRAs should consider whether there is an objective technological necessity for the obligatory equipment to be considered as part of the ISP network. If there is not, and if the choice of terminal equipment is limited, the practice would be in conflict with the Regulation.” > Not only is this subject to national definitions and implementations, it also allows for exceptions under “objective technological necessity”. Among other things, the draft guidelines go into a lot of detail with regards to the consequence of the different options that exist. > > As explained above, the RIPE NCC has no immediate position on which option is the better alternative. However, it could impact our engagement strategy in the longer term. > > There are roughly two alternative options: the modem or CPE is “obligatory” and as such will be supplied and maintained by the access provider as part of their network, or the end-user is allowed or even required to source their own equipment, which needs to be compatible with the network. > > The two different options would impact, for example, the RIPE NCC’s focus when it comes to IPv6 adoption. Although we have seen successful deployments under both scenarios, it is either the ISP that is in control and has to make the choice (which of course often means our members are deciding), or we need to somehow create awareness among end-users and engage more with manufacturers, importers and retailers to adopt equipment that supports IPv6. > > We also imagine that such a choice would impact the scale and, more importantly, the speed of IPv6 adoption. > > We also expect that if the prevailing choice would be to allow the end-user to select their own equipment, there will be an increased demand for strict standards and profiles to ensure interoperability. While the draft guidelines recognise that the CPE market is both competitive and innovative, we expect these discussions to lean towards additional certification requirements to ensure interoperability. > > In light of the current discussions about IoT security, especially in household appliances, we also see a big focus on the CPE as providing some security-related services. Several of these systems, such as SPIN and MUD/FUD, have been presented to the community. Again, a more scattered landscape where users select their own devices might make it challenging for these technologies to reach a sustainable level of adoption. > > More generally, we can expect that greater freedom of choice in selecting devices would come with some additional security challenges, where the increased variety could also lead to an increase in the variety of attack vectors and vulnerabilities. Also, as the CPE would no longer be in the ISP’s domain, we would lose the ability to quickly roll out patches and would instead have to trust the end-user or manufacturer to install updates in a timely fashion. > > Again, this is something where we would expect further discussion with regards to regulatory measures and (mandatory) certification to ensure minimum requirements are met and to protect the consumer. > > In either case, we trust the NRAs and the market to make an informed decision on the most appropriate approach and are happy to bring the RIPE community’s opinion forward to this consultation. Regardless of the outcome, we will continue to monitor these discussions and adjust our engagement strategy accordingly, both towards policymakers as well as the various market participants and, where necessary, the end-users. > > Regards, > > Marco Hogewoning > External Relations, RIPE NCC > > > _______________________________________________ > connect-wg mailing list > connect-wg(a)ripe.net > https://lists.ripe.net/mailman/listinfo/connect-wg -- Steve(a)nashfamily.me.uk is now my personal email address.

4 5

FW: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)
by Erik Bais 17 Oct '19

17 Oct '19

Dear Connect WG, As co-chair of the Address Policy WG, I would like to inform you at the following AP-WG proposal by Remco van Mook to adjust the default allocation size for IXP space. The discussion will be on a AP-WG mailing list and I would suggest to the Connect WG to provide your experience and input on this idea. This will have an impact on your business/operation .. we need to receive your view and insight. Regards Erik Bais On behalf of the AP-WG Chair collective On 15/10/2019, 14:43, "address-policy-wg on behalf of Marco Schmidt" <address-policy-wg-bounces(a)ripe.net on behalf of mschmidt(a)ripe.net> wrote: Dear colleagues, A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs" is now available for discussion. This proposal aims to change the default IXP assignment size from a /24 to a needs-based model, with a /27 as a minimum. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-07 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 13 November 2019. Regards, Marco Schmidt Policy Officer RIPE NCC

1 0

BEREC consultation: Identification of the network termination point
by Marco Hogewoning 16 Oct '19

16 Oct '19

Dear colleagues, Earlier this week, BEREC (Body of European Regulators for Electronic Communications) announced a public consultation on their draft guidelines for interpreting the “network termination point (NTP)”. These guidelines have been designed in accordance with Article 61(7) of the European Electronic Communications Code to provide national regulatory authorities (NRAs) with guidance on how to interpret the EU directives and implement them in their national legislation. This consultation is open to the public. While the RIPE NCC has no particular position on this topic, we think it is important for the community to consider the impact of these guidelines. They could impact not only our members’ operations, but the RIPE NCC’s engagement strategy on a number of topics such as IPv6 and IoT security. We invite the Connect Working Group to discuss the proposed guidelines and, should it reach a rough consensus as determined by the chairs, the RIPE NCC is willing to submit that opinion as a response on behalf of the RIPE community. As we see pros and cons to either alternative, failure to reach consensus will mean we will not respond to this consultation on behalf of the RIPE community, but would instead encourage individual members to provide their own responses. I’ll provide a brief description of the problem space and the potential impact below, but I recommend reading the draft guidelines as they are posted on the BEREC website: https://berec.europa.eu/eng/document_register/subject_matter/berec/regulato… Please note that while BEREC’s deadline is 21 November, we would need a few days to process and file the formal response and we kindly request the working group to respect close of business on 15 November as its internal deadline to reach consensus. Key Issues One of the key questions laid out in the document is whether or not the CPE or modem is part of the NTP. EU Regulation 2015/2120 states with regard to Internet access services in article 3(1): > “End-users shall have the right to access and distribute information and content, use and provide applications and services, and use terminal equipment of their choice […]” The 2016 BEREC Guidelines on net neutrality rules (paragraphs 26 and 27) provide further guidance on the implementation and state: > “In considering whether end-users may use the terminal equipment of their choice, NRAs should assess whether an ISP provides equipment for its subscribers and restricts the end-users’ ability to replace that equipment with their own equipment, i.e. whether it provides ‘obligatory equipment’. > > Moreover, NRAs should consider whether there is an objective technological necessity for the obligatory equipment to be considered as part of the ISP network. If there is not, and if the choice of terminal equipment is limited, the practice would be in conflict with the Regulation.” Not only is this subject to national definitions and implementations, it also allows for exceptions under “objective technological necessity”. Among other things, the draft guidelines go into a lot of detail with regards to the consequence of the different options that exist. As explained above, the RIPE NCC has no immediate position on which option is the better alternative. However, it could impact our engagement strategy in the longer term. There are roughly two alternative options: the modem or CPE is “obligatory” and as such will be supplied and maintained by the access provider as part of their network, or the end-user is allowed or even required to source their own equipment, which needs to be compatible with the network. The two different options would impact, for example, the RIPE NCC’s focus when it comes to IPv6 adoption. Although we have seen successful deployments under both scenarios, it is either the ISP that is in control and has to make the choice (which of course often means our members are deciding), or we need to somehow create awareness among end-users and engage more with manufacturers, importers and retailers to adopt equipment that supports IPv6. We also imagine that such a choice would impact the scale and, more importantly, the speed of IPv6 adoption. We also expect that if the prevailing choice would be to allow the end-user to select their own equipment, there will be an increased demand for strict standards and profiles to ensure interoperability. While the draft guidelines recognise that the CPE market is both competitive and innovative, we expect these discussions to lean towards additional certification requirements to ensure interoperability. In light of the current discussions about IoT security, especially in household appliances, we also see a big focus on the CPE as providing some security-related services. Several of these systems, such as SPIN and MUD/FUD, have been presented to the community. Again, a more scattered landscape where users select their own devices might make it challenging for these technologies to reach a sustainable level of adoption. More generally, we can expect that greater freedom of choice in selecting devices would come with some additional security challenges, where the increased variety could also lead to an increase in the variety of attack vectors and vulnerabilities. Also, as the CPE would no longer be in the ISP’s domain, we would lose the ability to quickly roll out patches and would instead have to trust the end-user or manufacturer to install updates in a timely fashion. Again, this is something where we would expect further discussion with regards to regulatory measures and (mandatory) certification to ensure minimum requirements are met and to protect the consumer. In either case, we trust the NRAs and the market to make an informed decision on the most appropriate approach and are happy to bring the RIPE community’s opinion forward to this consultation. Regardless of the outcome, we will continue to monitor these discussions and adjust our engagement strategy accordingly, both towards policymakers as well as the various market participants and, where necessary, the end-users. Regards, Marco Hogewoning External Relations, RIPE NCC

3 2

Minutes from RIPE 78
by remco van mook 10 Oct '19

10 Oct '19

Dear all, In order to prevent another red-face moment, please find below the draft minutes from the previous meeting. I trust you will read them all carefully so we can sign off on them during our next meeting! Kind regards Remco Co-chair of Connect-WG Connect Working Group RIPE 78 22 May 2019, 11:00-12:30 WG co-Chairs: Remco van Mook, Florence Lavroff, Willem van Gullik Scribe: Rumy Spratley-Kanis 1. Opening (Welcome, scribe appointment, agenda, proposed session format) The presentation is available at: https://ripe78.ripe.net/archives/video/50/ Florence asked attendees what businesses they worked in; this was measured by a show of hands and is as follows in descending order: - IXP - ISP - Content - Enterprise - Educational network 2. The Elusive Internet Flattening: 10 Years of IXP Growth Ignacio Castro, Queen Mary University of London The presentation is available at: https://ripe78.ripe.net/archives/video/51/ Nina Bargisen (Netflix) asked if, with IXP, Ignacio meant public peering. He confirmed that he collected public peerings from the peering DB. Nina said it makes some of the conclusions confusing because when there is a big flow in an IXP, it is moved to private interconnections. These peerings should be included to assess if the Internet is getting flatter because of Internet exchanges. All operators do private interconnections, so it would be useful to adjust the methods and include these. Nina asked Ignacio to study each of the CDNs and how they route their clients because not all the CDNs do it the same way. Ignacio agreed with the comments about private peering but he felt constrained due to having to look at historical data, which doesn’t include changes in redirection strategies. Martin Levy (Cloudflare) pointed out that the graph on slide 27 doesn't tell the full story. The divergence is partly a business model of the different players and is not a reflection of the IXPs in any way. While the graph is correct, it doesn’t tell whether we are better connected today than 15 years ago. He added that the graph by itself wasn’t flattering for Internet exchanges; even if they are the saving grace for how the internet works today. He asked whether Ignacio could share any data that wasn't based on IXP data. Ignacio empathised with Martin's comment, then explained that it was very difficult to find data with the limitations that were in place. He agreed that looking at redundancy multihoming would be an extra metric that would be interesting to review. In the end, he tried to look at two relatively simple metrics that are comparable over time and easy to convey. Martin commended him on his study. Andrew Sullivan (ISOC) mentioned that he was troubled by the last discussion. The numbers and graphs seemed to contradict the work done by IXPs. This may lead to an incorrect conclusion that IXPs are not worth the investment – he did not believe this. He encouraged Ignacio to find additional numbers to show a complete picture. Ignacio mentioned that his original plan for this work was “should I build an IXP?” His intent was not to say IXPs don’t matter, his message was, that in the specific metrics he looked at, the impact was as expected, particularly with regards to path length. The impact of transit dependence was clear. Blake Willis (Zayo / iBrowse / L33) added to Nina's point about private interconnects (PNIs) saying it would be interesting if Ignacio could dig into his data and analyse when a path moved from an IXP to a PNI. This could be a way to analyse where the bigger flows are. 3. RPKI at Route Servers Follow Up Nick Hilliard, INEX The presentation is available at: https://ripe78.ripe.net/archives/video/53/ Marja Jan Matejka (CZ.NIC), a developer of Bird, mentioned that in Bird Version 2, there is a special feature called Custom Route Attribute. This feature allows you to name and use your route attribute instead of these defined contents. He suggested that this would be much faster. He asked why they weren’t doing both RPKI and IRR DB? Nick replied they do both, but they start with RPKI filtering. If it fails the RPKI validation, it will drop the prefix, and if it’s unknown, it will pass through the IRR DB. However, the ASN check has to be evaluated first, so it’s IRR DB AS check, followed by RPKI validation, followed by regular IRR DB validation if it’s RPKI unknown. A participant asked whether they also do comparison evaluations against, for instance, FRR. Nick replied that they hadn’t tried FRR because there hadn’t been a huge amount of code changes for the route server code paths in FRR. Also, there were scaling problems with Quagga. There are other issues with FRR it being more difficult to do atomic config changes and updates, and the FRR will need a little bit more work before they can use it. Aris Lambrianidis from AMSIX asked whether they had a change of heart with regards to implementing RPKI in the EU route servers. Nick said this was a good question – and for them, this was more a policy issue rather than a technical issue. They were previously sceptical about RPKI implementation because when seen from a very high level, it creates a single point of failure. If compromised, for example, at an RIR, a red button could be pressed to disable a particular prefix or set of prefixes. Before, the BGP inter-domain ecosystem was based on a peer-to-peer system with filtering arrangements between organisations, whereas now there is a top-down thing which is controlled by the RIRs. He added there had been an increase in the amount of BGP hijacking that is difficult to deal with unless you implement a tool like RPKI. Like any policy decision, it’s a balance between not implementing something that could potentially cause problems, and implementing something that could fix a problem you already have. In the last few years, RPKI has seen various changes at a policy level. There is now jurisprudence about how courts interact with organisations like the RIPE NCC about deregistering prefixes, and there is much clearer understanding from a legal point of view. So, they looked at all the issues from a technical and a policy angle and concluded that RPKI was a good way to go. Randy Bush (Internet Initiative Japan) mentioned that RPKI is a database and this means RPKI based origin validation. He added that while it will help, it is not a magic bullet. Nick confirmed and agreed with Randy. He added that if hijacks and misconfigurations were easy to solve, they would have been solved years ago. RPKI makes it more difficult to make bigger mistakes. 4. BGP Filtering on AS15169 Using IRR and Other Data Arturo Servin, Google The presentation is available at: https://ripe78.ripe.net/archives/video/56/ Ruediger Volk (Deutsche Telecom) asked why they are not considering to mark the regular RPKI evaluation early on, as marking and reporting what looks invalid would be a good idea and helpful from the beginning. Arturo replied that he and Chris have considered it and will be further discussed. Ruediger asked why they were considering RPKI as a source only for invalidating IRR data. Why not include the RPKI ROA data sets as an additional quality source of route information? Arturo replied that they will when they are ready to use it. Ruediger mentioned that if they don’t have the tools, he has them. Arturo added that RPKI only has the origin, and they need more, but they will not use one signal, they need more signals to make it reliable. Ruediger said that Arturo was only talking about acceptance, it would be nice to have a slide with what they are publishing, as authoritative information from their peers. Arturo said that his presentation was short, but they are fixing all their internal systems to ensure that data in the IRR is correct and that what is in there, is exactly what they want to announce. They are also working on publishing their ROAs. This will happen in the next quarter, along with a lot of other parts that need fixing. Ruediger replied that it would be nice to have a summary at some point. Arturo said that they have also joined MANRS. To show their commitment to fixing this problem and be part of the solution rather than just the problem, they are working with ISOC to make MANRS more successful. Cleaning up and filtering is something Google wants to do and is committed to, and so they are in the process, but it will take some time. Magnus, a remote chat participant, asked if they could open their IRR software. Arturo said they don’t have an IRR software, but they do have some tools that they use to parse the information. Chris Morrow, Arturo’s colleague from Google, replied that he had written some IRR parsing software, available on GitHub, it still needs work, but once finished, it could be used to parse the data and create filters. They will spend more time on that. Randy Bush commented on the slide “How do I peer with AS15169?” He asked if that included the transitive closure. If Randy, a BGP speaker, were not their peer, but a customer of their peer, would they accept his prefix from their peer if his prefix did not have an IRR Object? Arturo replied that they wouldn’t because there wouldn’t be any authorisation in place. Paul Hoogsteder, a remote chat participant, asked if Arturo could explain what is meant with “follow the AS/arrow maintainer”? Arturo replied that in the IRR, you have the maintainer, the AS-SET and the ASN object. They check the ASN object and check if it is an ASN they peer with. But they need to know all the routing information, which is in the AS-SET. So if someone peers with them and doesn’t put the ASN-SET in the ISP.google.com, one of the ways they find the AS-SET that has all the ASNs or all the information related to that ASN is by going to the peering DB to check the ASN-SET. Brian Dickson (GoDaddy) asked if a BGP speaker with their own AS, peering with Google directly and has RPKI but no IRR object or AS path, would Google not accept routes from them? Arturo confirmed that for now, they wouldn’t. He added that NTT has a way to export from RPKI to IRR’s, but they hadn’t decided if they were going to use it. This will be discussed. Brian asked if AS cone were to get formalized and adopted, would they use it? Plus RPKI? Arturo replied that he wasn’t sure you can put AS cone in the RPKI. All they know is that the prefix as an origin. Brian clarified AS cone if it does go into the RPKI. Arturo replied that if that were the case, including AS PA, then maybe they would adopt it. An anonymous remote chat participant asked if they were doing filtering before this, and based on what information? Arturo replied that they didn’t do any filtering, they just had the prefix, the number of prefixes – Chris will answer: Chris Morrow (Google) added that they were doing less filtering, not none. 5. Connect Update Florence Lavroff The presentation is available at: https://ripe78.ripe.net/archives/video/57/ There were no questions or comments. 6. Euro-IX Update Bijal Sanghani, Euro-IX The presentation is available at: https://ripe78.ripe.net/archives/video/58/ There were no questions or comments. 7. IXPDB and Tools Jesse Sowell, The Bush School of Government and Public Service, Texas A&M University The presentation is available at: https://ripe78.ripe.net/archives/video/59/ There were no questions or comments. 8. Offline Discussion There was no discussion 9. Closure

1 0

Working Group agenda, RIPE 79
by Florence Lavroff 02 Oct '19

02 Oct '19

Dear friends of the Connect WG, RIPE 79 is around the corner. Here is the agenda for our next Working Group session on Wednesday, October 16th from 11:00 to 12:30 : 1 Opening (Welcome, scribe appointment, agenda, proposed session format) 2 Raci #1 - Dismantling Operational Practices of BGP Blackholing at IXPs, Marcin Nawrocki, Freie Universitaet Berlin - 10 min 3 Raci #2 - Keeping state election infrastructure safe: How Cloudflare and local IXP connectivity helped a small country in Europe, Vladislav Bidikov, Faculty of Computer Science and Engineering / IXP.mk - 10 min 4 IX-API: An API for Automating Interconnection, Thomas King, DECIX - 15 min 5 IPv6 adoption on Internet Exchanges, Susan Forney, Hurricane Electric - 15 min 6 Euro-IX update - Bijal Sanghani, Euro-IX - 3 min 7 Connect update - Florence Lavroff - 3 min 8 Offline discussion 9 Closure See you in Rotterdam ! Best regards, Florence, Remco and Will Connect-WG co-chairs -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Infrastructure Acquisition and Interconnect / Google EMEA

1 0