At last month’s Internet Engineering Task Force meeting in Montreal, Canada (IETF 105), my colleagues — Sheng Jiang and Guangpeng Li from Huawei — and I presented two new proposals to improve the efficiency and functionality of IPv6.
Asymmetric IPv6 for IoT networks
The first, ‘Asymmetric IPv6 for IoT Networks’, is a new proposal to make IPv6 more friendly to the tiny devices at the edges of the Internet of Things. Not only devices such as sensors or actuators, but also the first-hop routers that have very limited battery, memory and processing capacity, and very low bit rate. Therefore, it is essential to minimize the size of network packets without increasing the complexity of processing them.
There are existing proposals in this area (most recently ‘Static Context Header Compression’) but Asymmetric IPv6 adds the idea of using truncated IPv6 addresses within an IoT domain and missing out parts of the IPv6 header that are, in practice, redundant. Therefore, all nodes including routers can process packets more efficiently and with less battery consumption.
The solution is ‘asymmetric’ because, for example, the source address of a packet might be truncated to 16 bits even if the destination was a full 128-bit IPv6 address. As a result, the header of an IPv6 packet might be reduced to as little as 8 or 10 bytes, compared to the normal 40. At the boundary between the IoT domain and the Internet, outgoing packet headers would be expanded to the normal size, and incoming headers would be shortened.
After initial discussions in Montreal, we will continue to work to ensure that the proposal fits in well with ongoing work by other IETF participants.
Service oriented IP
The second proposal, Service Oriented IP (SOIP), is more radical. It applies to a typical ISP network, or an enterprise network, in which client systems wish to use various services.
Today, clients (sometimes including human users) have to first worry about reachability — how to reach a particular IP address or a particular URL. However, their real goal is to reach a service — such as a storage service or a computation service. It may be provided by their primary service provider, or it may be anywhere in the Internet.
SOIP handles this by considering that user requests should be directed primarily at a service type, not at an address. Unconventionally, SOIP brings this down to the packet switching layer. There is no destination address in a SOIP packet from a client to the first-hop router; there is a code byte known as a Service Action Type (SAT) instead. The router will forward the packet towards the appropriate service gateway or proxy.
If the service is installed locally, the whole transaction may run over SOIP. If the service is remote, the transaction will be relayed over conventional IPv6 or IPv4.
For compatibility, all SOIP clients will also be fully functional IPv6 clients, and SOIP will support the establishment of IPv6 connections, and IPv4-as-a-service connections when needed.
Does SOIP sound like a layer violation, with application layer information in the network layer header? Yes, that’s exactly right. Given that Internet services are now largely mediated by middleboxes whose function is at odds with the traditional end-to-end model, SOIP attempts to make the middlebox model work better, to the benefit of both clients and service providers.
Over the coming months, we will be developing these ideas and the necessary mechanisms. If you have any further feedback, leave a comment below.
Brian E. Carpenter is an Honorary Professor of Computer Science at the University of Auckland.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.