"The Internet of Things - a techie's viewpoint" by Jan Newmarch is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Based on a work at https://jan.newmarch.name/IoT/.
The IETF is only concerned with a subset of the networking stack. With regard to home networking, they concentrate on what is required of Layer 3 services. The current principal document regarding homenet is RFC 7368 IPv6 Home Networking Architecture Principles . This assumes that whereas most home systems are based on IPv4, future systems will be primarily IPv6. The architecture is targetted to IPv6, with little mention of IPv4.
NAT has long been used in the IPv4 world for two purposes: to overcome the shortage of IPv4 addresses and to hide interfaces from the wider network. While the first is recognised as possibly necessary until the widespread adoption of IPv6, problems arising from the second often cause NAT to be labelled as 'evil.'
RFC 2993: Architectural Implications of NAT lists these issues:
Hiding IP addresses behind a NAT router causes many problems. For example, if a packet contains the IP address of the sender as part of the data, then this addres will be wrong. Rewriting packet headers won't solve this.
Another important case arises with services such as Skype or Wechat where an endpoint is required to be visible so that it can be connected to. Without configuring the NAT router, a trick commonly used is for the endpoint to set up a long lived TCP connection to a well-known server. This is permissible as it is an outgoing connection. An external entity wishing to connect to this endpoint first queries the well-known server to get information about this TCP connection. It then 'borrows' the connection using 'hole punching', and uses it to talk to the endpoint. Not a very nice technique!
The last point refers to general software. There is a variation on this for specifically IoT devices: many IoT devices (such as lights, air conditioners, etc) can be controlled from outside their own network. This is done by the device registering with a vendor's server and maintaining a long-lived connection to that server. Your remote app (or whatever) sends commands via that server. Not as bad technically as 'hole punching' but on the other hand it is a privacy issue: the vendor's server knows what you are doing all the time to its devices. Ownership of the data is not restricted to you but is shared with the vandor.
IPv6 has a NAT equivalent in RFC 6296 IPv6-to-IPv6 Network Prefix Translation but does not recommend its use.
We are all familiar with the enormous address space of IPv6 and how every device can have its own IP address. With 128 bits to each address, you will often see figures of 2128 for the address space. While true, it isn't quite that simple: IPv6 addresses fall into several categories.
The first point to note is that a unicast address is typically divided into two parts: a 64 bit interface identifier and a 64 bit routing address. The interface identifier is normally derived from the interface's 48 bit MAC address. The routing address is used to give routing information, and also to classify the type of packet.
The major packet types are
The homenet's ISP will normally give a routing prefix, upto 64 bits, with the remaining bits used for subnetting within the home. For example, if the ISP's routing prefix is a /64, then there is only one subnet, if it is a /60 then there could be upto 24 (16) subnets and so on.
The homenet architecture document points to the increasing use of multiple subnets in the home even under IPv4, such as the home network, a guest subnetwork and possibly a VPN network for work-related purposes. In the future there may be even more: a subnet for low power 6LoWPAN devices; a subnet for the lights in a room; a subnet for all the devices in a room (noting that a NIC may have multiple IPv6 addresses and hence belong to multiple subnets); a subnet of devices for each of the different occupants in the house, are all possibilities.
The architecture does not impose limits to the internal structuring within the home, save to rule out any NAT-ing techniques. At a minimum, it implies that being given a /64 prefix by an ISP will not be acceptable. While a /48 is desirable (giving upto 216 subnets), a /56 may be okay (giving upto 28, or 256 subnets). Less than that is probably not enough and should be signalled to the home occupier(s) in some way.
A node will likely have many addresses: it will always have a link local address, and will maybe have a number of unique local and unique global addresses. Devices that it wishes to communicate with will have a similar range of addresses.
For communication between devices in the same site, the architecture recommends using the unique local addresses. These are immune to outages in a conection to the ISP, and are stable with respect to any changes made by the ISP. Use of these addresses also keeps the information exchange completely local, which otherwise might have security implications.
The homenet is expected to have a variety of layer 2 systems: fast ethernet, ethernet over powerlines, WiFi, low power wireless and so on. Some of these will have resource constraints, both computationally and power-wise. Some nodes may be in sleep mode while others will be always-on, for example.
Routers will need to be aware of internal and external network boundaries, and after reboot will need to bring the network up in its previous state.
It is also expected that often no systematic network administration will be performed (i.e. users will expect plug 'n play). Those with a little knowledge may manually configure systems which are inconsistent, while those with a high degree of knowledge will want the ability to custom-tune their network.
It is expected that current router configuration and even routing protocols may not prove adequate for future scenarios, pointing to a great deal of future work in this area.
It isn't feasible for anyone to remember IPv6 addresses, let alone use them to interact with devices. Each device will need a name. For many devices this name may not be important to a user (such as the garden sprinkler underneath the third rose bush on the left) but in many cases it will, such as the main light in the kitchen.
Devices should have a means of giving themselves default names, and checking that these are unique within the network. There should also be a means for users to overide these where possible. Again, the mechanisms for doing this are outside the scope of the architecture document.
There are a multiplicity of service architectures and corresponding service discovery systems. Well known ones include Corba and Java Naming Services, the UPnP discovery system SSDP and many others. Optimistically perhaps the architecture calls for compatibility in some way with the DNS system, so that they can be integrated into the standard DNS.
Copyright © Jan Newmarch, jan@newmarch.name
"The Internet of Things - a techie's viewpoint" by Jan Newmarch is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Based on a work at https://jan.newmarch.name/IoT/.
If you like this book, please donate using PayPal