D3.6.1: Cookbook for IPv6 Renumbering in SOHO and Backbone Networks

In this text we present the results of a set of experiments that are designed to be a first step in the process of analysing how effective network renumbering procedures may be in the context of IPv6. An IPv6 site will need to get provider assigned (PA) address space from its upstream ISP. Because provider independent (PI) address space is not available for IPv6, a site wishing to change provider will need to renumber from its old network prefix to the new one. We look at the scenarios, issues and enablers for such renumbering, and present results and initial conclusions and recommendations in the context of SOHO and backbone networking. A subsequent deliverable (D3.6.2) will refine these findings, adding additional results and context from enterprise and ISP renumbering scenarios

Development of a Graduate Course on the Transition to Internet Protocol Version 6

Internet and mobile connectivity has grown tremendously in the last few decades, creating an ever increasing demand for Internet Protocol (IP) addresses. The pool of Internet Protocol version 4 (IPv4) addresses, once assumed to be more than sufficient for every person on this planet, has reached its final stages of depletion. With The Internet Assigned Numbers Authority’s (IANA) global pools depleted, and four of the five Regional Internet Registries (RIR) pools down to the their last /8 block, the remaining addresses will not last very long. In order to ensure continuous growth of the internet in the foreseeable future, we would need a newer internet protocol, with a much larger address space. Specifically, with that goal in mind the Internet Protocol version 6 (IPv6) was designed about two decades ago. Over the years it has matured, and has proven that it could eventually replace the existing IPv4. This thesis presents the development a graduate level course on the transition to IPv6. The course makes an attempt at understanding how the new IPv6 protocol is different than the currently used IPv4 protocol. And also tries to emphasize on the options existing to facilitate a smooth transition of production networks from IPv4 to IPv6

IPv6 Network Mobility

Network Authentication, Authorization, and Accounting has been used since before the days of the Internet as we know it today. Authentication asks the question, “Who or what are you?” Authorization asks, “What are you allowed to do?” And fi nally, accounting wants to know, “What did you do?” These fundamental security building blocks are being used in expanded ways today. The fi rst part of this two-part series focused on the overall concepts of AAA, the elements involved in AAA communications, and highlevel approaches to achieving specifi c AAA goals. It was published in IPJ Volume 10, No. 1[0]. This second part of the series discusses the protocols involved, specifi c applications of AAA, and considerations for the future of AAA

Traversing NAT: A Problem

This quasi-experimental before-and-after study measured and analyzed the impacts of adding security to a new bi-directional Network Address Translation (NAT). Literature revolves around various types of NAT, their advantages and disadvantages, their security models, and networking technologies’ adoption. The study of the newly created secure bi-directional model of NAT showed statistically significant changes in the variables than another model using port forwarding. Future research of how data will traverse networks is crucial in an ever-changing world of technology

NAT denial of service: An Analysis of translation table behavior on multiple platforms

Network Address Translation or NAT, is a technology that is used to translate internal addresses to globally routable addresses on the internet. It is used extensively in almost every network requiring global connectivity due to the current lack of IPv4 addresses. The primary mechanism used to facilitate the translation of internal addresses to external addresses and vice versa is the translation table. This study takes an in-depth look at how five different vendors: Cisco, Extreme, Linksys, VMWare, and Vyatta, implement the translation table during active NAT sessions. Additionally, this study analyzes the methodology required to fill a translation table and the Denial of Service that is a result of the attack. We consider the relative difficulty of accomplishing this task between the different platforms and protocols (TCP vs UDP vs ICMP). We conclude this study with steps that can be taken to prevent or mitigate the NAT DOS attack

A New Addressing and Forwarding Architecture for the Internet

The current Internet routing and addressing architecture is facing a serious scalability problem. The default free zone (DFZ) routing table size grows at an increasing and potentially alarming rate. The Internet architecture uses a single namespace - the IP address, to express two functions about a network entity: its identifier and locator. This overloading of semantics leads to the scalability problem as a consequence of multihoming, traffic engineering, and nonaggregatable address allocations. The current Internet architecture does not inherently support emerging features such as mobility either. This thesis presents a simple addressing and forwarding architecture (SAFA) for the Internet. SAFA separates the locator namespace from the ID namespace so that the locators can follow the hierarchies in the Internet topology and be aggregated. The locators are allocated dynamically and automatically. The hierarchical format of locators gives end systems more control over the route selection. A straightforward forwarding scheme is designed based on the hierarchical addressing scheme. The meshed part of the Internet topology is integrated into the forwarding procedure through a special forwarding table. With a rendezvous service that maps from IDs to locators, SAFA also provides scalable support for mobility, multihoming and traffic engineering. Our work also includes an Internet topology study and a prototype implementation of the architecture. The evaluation results suggest that SAFA would be feasible in the current Internet if deployed

IP and ATM integration: A New paradigm in multi-service internetworking

ATM is a widespread technology adopted by many to support advanced data communication, in particular efficient Internet services provision. The expected challenges of multimedia communication together with the increasing massive utilization of IP-based applications urgently require redesign of networking solutions in terms of both new functionalities and enhanced performance. However, the networking context is affected by so many changes, and to some extent chaotic growth, that any approach based on a structured and complex top-down architecture is unlikely to be applicable. Instead, an approach based on finding out the best match between realistic service requirements and the pragmatic, intelligent use of technical opportunities made available by the product market seems more appropriate. By following this approach, innovations and improvements can be introduced at different times, not necessarily complying with each other according to a coherent overall design. With the aim of pursuing feasible innovations in the different networking aspects, we look at both IP and ATM internetworking in order to investigating a few of the most crucial topics/ issues related to the IP and ATM integration perspective. This research would also address various means of internetworking the Internet Protocol (IP) and Asynchronous Transfer Mode (ATM) with an objective of identifying the best possible means of delivering Quality of Service (QoS) requirements for multi-service applications, exploiting the meritorious features that IP and ATM have to offer. Although IP and ATM often have been viewed as competitors, their complementary strengths and limitations from a natural alliance that combines the best aspects of both the technologies. For instance, one limitation of ATM networks has been the relatively large gap between the speed of the network paths and the control operations needed to configure those data paths to meet changing user needs. IP\u27s greatest strength, on the other hand, is the inherent flexibility and its capacity to adapt rapidly to changing conditions. These complementary strengths and limitations make it natural to combine IP with ATM to obtain the best that each has to offer. Over time many models and architectures have evolved for IP/ATM internetworking and they have impacted the fundamental thinking in internetworking IP and ATM. These technologies, architectures, models and implementations will be reviewed in greater detail in addressing possible issues in integrating these architectures s in a multi-service, enterprise network. The objective being to make recommendations as to the best means of interworking the two in exploiting the salient features of one another to provide a faster, reliable, scalable, robust, QoS aware network in the most economical manner. How IP will be carried over ATM when a commercial worldwide ATM network is deployed is not addressed and the details of such a network still remain in a state of flux to specify anything concrete. Our research findings culminated with a strong recommendation that the best model to adopt, in light of the impending integrated service requirements of future multi-service environments, is an ATM core with IP at the edges to realize the best of both technologies in delivering QoS guarantees in a seamless manner to any node in the enterprise

Correlating IPv6 addresses for network situational awareness

The advent of the IPv6 protocol on enterprise networks provides fresh challenges to network incident investigators. Unlike the conventional behavior and implementation of its predecessor, the typical deployment of IPv6 presents issues with address generation (host-based autoconfiguration rather than centralized distribution), address multiplicity (multiple addresses per host simultaneously), and address volatility (randomization and frequent rotation of host identifiers). These factors make it difficult for an investigator, when reviewing a log file or packet capture ex post facto, to both identify the origin of a particular log entry/packet and identify all log entries/packets related to a specific network entity (since multiple addresses may have been used). I have demonstrated a system, titled IPv6 Address Correlator (IPAC), that allows incident investigators to match both a specific IPv6 address to a network entity (identified by its MAC address and the physical switch port to which it is attached) and a specific entity to a set of IPv6 addresses in use within an organization\u27s networks at any given point in time. This system relies on the normal operation of the Neighbor Discovery Protocol for IPv6 (NDP) and bridge forwarding table notifications from Ethernet switches to keep a record of IPv6 and MAC address usage over time. With this information, it is possible to pair each IPv6 address to a MAC address and each MAC address to a physical switch port. When the IPAC system is deployed throughout an organization\u27s networks, aggregated IPv6 and MAC addressing timeline information can be used to identify which host caused an entry in a log file or sent/received a captured packet, as well as correlate all packets or log entries related to a given host

IPv6: a new security challenge

Tese de mestrado em Segurança Informática, apresentada à Universidade de Lisboa, através da Faculdade de Ciências, 2011O Protocolo de Internet versão 6 (IPv6) foi desenvolvido com o intuito de resolver alguns dos problemas não endereçados pelo seu antecessor, o Protocolo de Internet versão 4 (IPv4), nomeadamente questões relacionadas com segurança e com o espaço de endereçamento disponível. São muitos os que na última década têm desenvolvido estudos sobre os investimentos necessários à sua adoção e sobre qual o momento certo para que o mesmo seja adotado por todos os players no mercado. Recentemente, o problema da extinção de endereçamentos públicos a ser disponibilizado pelas diversas Region Internet registry – RIRs - despertou o conjunto de entidades envolvidas para que se agilizasse o processo de migração do IPv4 para o IPv6. Ao contrário do IPv4, esta nova versão considera a segurança como um objetivo fundamental na sua implementação, nesse sentido é recomendado o uso do protocolo IPsec ao nível da camada de rede. No entanto, e devido à imaturidade do protocolo e à complexidade que este período de transição comporta, existem inúmeras implicações de segurança que devem ser consideradas neste período de migração. O objetivo principal deste trabalho é definir um conjunto de boas práticas no âmbito da segurança na implementação do IPv6 que possa ser utilizado pelos administradores de redes de dados e pelas equipas de segurança dos diversos players no mercado. Nesta fase de transição, é de todo útil e conveniente contribuir de forma eficiente na interpretação dos pontos fortes deste novo protocolo assim como nas vulnerabilidades a ele associadas.IPv6 was developed to address the exhaustion of IPv4 addresses, but has not yet seen global deployment. Recent trends are now finally changing this picture and IPv6 is expected to take off soon. Contrary to the original, this new version of the Internet Protocol has security as a design goal, for example with its mandatory support for network layer security. However, due to the immaturity of the protocol and the complexity of the transition period, there are several security implications that have to be considered when deploying IPv6. In this project, our goal is to define a set of best practices for IPv6 Security that could be used by IT staff and network administrators within an Internet Service Provider. To this end, an assessment of some of the available security techniques for IPv6 will be made by means of a set of laboratory experiments using real equipment from an Internet Service Provider in Portugal. As the transition for IPv6 seems inevitable this work can help ISPs in understanding the threats that exist in IPv6 networks and some of the prophylactic measures available, by offering recommendations to protect internal as well as customers’ networks