The Beyond Connectivity Services Mindset
Salah M. S. Al-Buraiky
Data Network Engineer, Communication Solutions Engineering Group,
Saudi Aramco

The Internet protocol (IP) is a minimalist protocol that provides simple universal connectivity. Its main function is to provide efficient and seamless end-to-end datagram delivery. The power of IP and its sphere of applicability can be greatly extended by enabling the use of a more generic host model and enabling the use of delivery models with more specific guarantees in certain aspects.

The capabilities resulting from extending the network layer functions can be collectively termed as Beyond Connectivity Services (BCS). This includes IP multicast, IP security, IP mobility and IP QoS. Multicast extends efficient end-to-end datagram delivery to multi-end-to-multi-end efficient delivery. IP mobility waives static location as a condition for seamless datagram delivery. QoS provides performance guarantees to the delivery process. IP security provides confidentiality and authenticity guarantees to the delivery. Those advanced (beyond basic connectivity) IP features are generic services that the network layer can offer to any upper layer protocol.

The current incarnation of the Internet protocol, IPv4, wasn’t born with those capabilities. They were back-fitted onto it at different stage of its lifetime. They are now widely available on many platforms and in many networks but there are serious limitations in deploying and benefiting from them. Those limitations stem from the limited address space of IPv4, its relatively rigid mechanism for supporting options and its large installed base, which limit the freedom protocol designers have in mandating them and in changing the base protocol specifications to optimally accommodate them. Today’s Internet is largely a unicast network with no mobility support, no QoS support and with mostly insecure protocols.

The IPv6 vision regarding BCS capabilities is that they should be scalable, flexibly applicable and mandatory. Scalability means that IPv6 is designed to support those functionalities Internet-wide and not only within enterprise networks. Flexible applicability means that IPv6 should provide much more flexibility in combining those functions together and in using them with other protocols. Security shouldn’t be a hindrance to providing QoS or multicast, for example.

Mandating those capabilities with IPv6 is not merely a formality and has important protocol-level and platform-level implications. Multiple benefits can be realized when the existence of those capabilities is taken for granted by protocol and platform designers.

Mandatory IPSec support, for example, relieves protocol designers from devising protocol-specific security mechanisms when a generic security mechanism is already provided by the network stack. OSPFv3 (RFC 2740), which is the OSPF version designed for IPv,6 exemplifies this benefit, as it (in contrast to OSPFv2) relies on IPSec for security rather than specifying its own security mechanism.

At the platform level, efficient and more compact system implementations are realized by having protocol security centralized within a single system component, where security hardening and optimization are concentrated.

IPv6 is well positioned on multiple levels to achieve its vision regarding BCS services. With IPv6, there is a real opportunity to make the Internet a network that is mobility-friendly, protocol-secure, multicast-capable and QoS-aware. Awareness of the need for BCS functions prior to the initiation of the IPv6 protocol design process, and the experience with BCS functions accumulated over years of large scale IPv4 deployment are strong advantages for BCS protocol designers as they help avoid design mistakes, help realize what the base protocol needs to facilitate supporting BCS functions, and help account for the simultaneous use of more than one BCS function.

The large IPv6 address space enables it to dispense with NAT, which is a major hindrance to deploying BCS services. It also provides plenty of addresses to assign to the different functional components those services needed, such as multicast groups and mobility care of addresses (addresses distributed to visiting nodes). In addition, and perhaps unexpectedly, information needed by the various BCS functions can be encoded into the long and highly structured IPv6 addresses, leading to elegant and efficient solutions to problems encountered in designing BCS functions. The embedded RP specification is an example of such leverage (RFC 3956).

Another specification exemplifying the value of longer addresses, aside from expanding the address space, is the Cryptographically Generated Addresses (CGA) standard, which utilizes the long IPv6 address to carry cryptographic tokens of validity. CGA addresses can be used, through the SEND (SEcure Neighbor Discovery) standard, to secure neighbor discovery against attacks similar to ARP (Address Resolution Protocol) poisoning. Both SEND and CGA achieved RFC status in March, 2005 (RFC 3971 & RFC 3972, respectively).

The powerful features of the base IPv6 protocol such as neighbor discovery (part of ICMPv6) and the fact that the IPv6 protocol isn’t widely deployed yet have been leveraged by BCS protocol designers. New ICMP messages (such as the “Home Agent Address Discovery Message”) and new options (such as the “Advertisement Interval Option”) for existing ICMP messages have been specified to provide built-in aids for mobile IPv6 to perform its functions, for instance. In addition, and most importantly, IPv6 provides a generic, efficient and flexible framework for extensibility through header chaining. Header chaining provides more efficient header processing and also enables carrying more options per packet (compared to IPv4).

Reflecting on the base IPv6 and BCS protocol standards reveals good examples of how the available experience and the properties of IPv6 provide solid foundations for scalability and flexible applicability. Tracking how IPv6 mobility and IPv6 multicast standards have evolved, for example, will insightfully show how those properties have enabled the designers to come up with practical and scalable solutions. Both BCS capabilities existed for IPv4, but with scalability limitations. PIM-SM (Protocol Independent Multicast – Sparse Mode), the de facto standard for multicast routing, has proven to be a scalable intra-domain multicast routing protocol. PIM-SM however requires a mechanism to map group addresses to a special router called the Rendezvous Point (RP), a requirement that is difficult to satisfy in a scalable manner across different administrative domains. Utilizing its long addresses, IPv6 provides an elegantly scalable mechanism for achieving this mapping by encoding the RP address in the multicast group address itself. This mechanism is known as embedded-RP (RFC 3956).

IP level mobility has been specified for IPv4, but didn’t enjoy widespread implementation due to difficulties in securely scaling the protocol. The extensibility of IPv6 enabled the standardization of practically achievable route optimization (RO), which is vital for scaling IP mobility. The efficient option handling of IPv6 enabled reducing the performance penalty of route optimization to an acceptable level. The IPv6 mobility specification also standardized the return routability (RR) mechanism, for ensuring that route optimization can be used to scale mobile IPv6 without introducing mobility-specific security threats to the Internet. The abundance of addresses provided by IPv6 enabled dispensing with foreign agents, which also contributes to scaling mobile IP.

Both Embedded-RP and Mobility for IPv6 achieved RFC status in 2004 (RFC 3956 & RFC 3775, respectively). Thus, utilizing its merits, IPv6 provides standard and scalable solutions for network layer mobility and for inter-domain multicast. These are major steps towards enabling large-scale IP mobility and IP multicast deployments, and have the potential of enabling Internet-wide mobility and multicast support.

Considering how IPv6 identifies flows provides an example of how its properties can improve the flexible applicability of BCS functions. Identifying flows, whether coarse-grained or fine-grained, is necessary for providing QoS. With IPv4, flows are identified using a 5-tuple of fields (a quintuplet) including two transport layer fields (the source and destination ports). IPv6, on the other hand, dedicates a header field called the flow label for flow identification, thus eliminating the need to inspect transport layer fields. This clean separation between layers enables IPSec to encrypt upper layer headers and payloads without hampering QoS.

The challenging issues that need to be approached for achieving the IPv6 BCS vision are not completely resolved yet. Combining multicast and mobility in an optimal fashion is a challenging problem that requires considering many compromises and different scenarios. Securing multicast is another area that still requires much standardization effort.

To expand the potential of IP-based networking, approaching network architecting, design and operation with a BCS mindset is crucial. In the IPv6 world, network architects, engineers and operators should account for deploying and managing BCS services in developing their network design, management and operational procedures, and address allocation plans. Full support of BCS functions should be a requirement in networking hardware and software selection. Organizations awarding compliance certificates should mandate or strongly encourage complete implementations of BCS functions in any platform claiming IPv6 support. Strongly endorsing BCS functions can significantly enhance the value of the IPv6 Internet, and enable applications that were extremely difficult or impossible to realize on the IPv4 Internet.