Hello all
==== Summary ====
We should use IPv6 global addresses instead of link-local. For that, all that
we need to do is use ff03::fd as the CoAP multicast address, instead of
ff02::fd.
==== Why ====
During some of the side-discussion that happened yesterday here at the OIC
members meeting, we came to the conclusion that we should no longer use link-
local addresses. This came after the discussion on whether the URIs in
payloads should be absolute or relative[1] and the multi-PHY proposal.
Larger industrial networks and even some home networks may be subdivided into
multiple network segments (multicast domains), so this functionality will
become necessary in the medium-term future. We're not asking for multicast
routing -- instead, a simple device that is multihomed, such as a 6LoWPAN /
Thread border router, can connect these two networks together.
If we keep to link-local addresses, this directory service cannot pass on
services to the "wrong" segment of the network, as those IPs cannot be
addressed. On the other hand, if we use global addresses, they can. Moreover,
in IPv6, those addresses should even be globally unique, so they can be used
by remote access (though direct connections initiated from the outside are not
likely to be accepted).
[1] answer: relative when referring to itself; absolute when a directory
service is referring to another device.
=== On IPv4 ===
This is actually already how IPv4 works. Most devices will not set up link-
local addresses (169.254.x.x) unless they have been unable to obtain an IP
address through static configuration or via DHCP. This means IoTivity operating
over IPv4 is already using global addresses, albeit reserved by RFC 1918.
Quite often, in large networks, those addresses are routable from different
network segments. NAT inside a network is uncommon. This means directory
services operating on multiple networks can easily provide the IPs of services
on all segments to any segment.
=== On IPv6 ===
We are currently using link-local multicast and unicast addresses. This
proposal applies to IPv6 only.
This proposal should seamlessly transition devices that have global addresses
to using them, but gracefully fall back to their link-local addresses in case
the global addresses are unavailable.
=== Other transports addressing via MAC (such as BTLE GATT profile) ===
MAC addresses are link-local and such devices do not have other addressing
means. Devices on those MAC/PHY layers are out of scope.
I personally expect this type of device to disappear over the next 2 years, as
they are replaced by 6Lo over multiple radio technologies, such as 6Lo over
802.15.4 (6LoWPAN), 6Lo over Bluetooth LE, IPv6 over ZigBee/ZWave/whatever.
When that happens, those devices fall back to the IPv6 case above.
==== How ====
As the summary says, all we need to do is use a different multicast address.
The reason for that is that is that everything in OIC starts with discovery
and we've designed the protocol so that IoTivity stack does not need to know
the device's IP addresses. That is to say, the IP stack knows its addresses
better than we do and it will fill in that address in the packets it sends
anyway.
If we start discovery using ff02::fd, which is a link-local multicast address,
the IP stack will always choose the link-local address associated with the
interface being sent on. Below, I tested on two Linux machines, machine A has
no IPv6 global address while machine B does.
both machines # tcpdump -pni any dst host ff02::fd &
machine-A # nc -q1 -u -6 ff02::fd%wlp2s0 5863 <<<hi
09:25:23.721639 IP6 fe80::5e51:4fff:fe7c:49f8.41573 > ff02::fd.5863: UDP,
length
3
machine-B # nc -q1 -u -6 ff02::fd%eth0 5863 <<<hi
08:43:18.117116 IP6 fe80::21c:14ff:fe01:12a3.60474 > ff02::fd.5863: UDP, length
3
As you can see, the sender's address is the link-local IPv6 address.
However, if we use ff03::fd, which is not link-local, automatically the IPv6
stack on the machine that has global addresses will use it:
both machines # tcpdump -pni any dst host ff03::fd &
machine-A # nc -q1 -u -6 ff03::fd 5863 <<<hi
09:27:41.897343 IP6 fe80::5e51:4fff:fe7c:49f8.59015 > ff03::fd.5863: UDP,
length
3
machine-B # nc -q1 -u -6 ff03::fd 5863 <<<hi
08:43:11.105319 IP6 2a01:4f8:d13:f81:21c:14ff:fe01:12a3.49439 > ff03::fd.5863:
UDP, length 3
==== Interactions ====
=== OIC spec ===
The OIC spec allows for this. The "IPv6 node requirements" section only talks
about "FF0x::FD", leaving the selection of the scope unspecified. Therefore,
using ff03::fd is permitted by the OIC spec and probably even encouraged.
=== Thread Group ===
Thread defines link-local addressing as those devices that can be reached
within one radio transmission and realm-local as those that are inside the
same Thread network. In fact, Thread already uses the ff03::fd multicast
address for its own purposes.
Therefore, I'd say that we are even *required* to use ff03::fd when operating
inside a Thread network if we want our multicast packets to reach all the
devices inside the network. This is supported by RFC 7346 section 5 "Definition
of Realm-local scope for IEEE 802.15.4". This requires some testing, though.
=== Unique Local Addresses ===
ULAs are a type of IPv6 global addresses that are not part of the global IPv6
Internet. That's kind of like RFC 1918 for IPv4, but unlike that, ULAs are not
used when communicating with the global world. There is no NAT in IPv6.
The problem here is that ULAs are global addresses, so it's possible that the
IPv6 stack chooses an ULA instead of a really-global global address when
sending the discovery. This might have some side-effects for remote access, but
should be few since ULAs are still supposed to be unique and we don't expect
to have unfirewalled access from the cloud to the internal network.
The biggest problem is that Thread uses ULAs for its Mesh-Local prefix
addresses and mandates that those addresses not be forwarded or routed outside
the mesh network. If the IPv6 stack were to choose the Mesh ULA, we wouldn't
get the benefits of the addressing... This needs to be investigated.
==== Code changes ====
John already has the code mostly ready for this. I only asked that we don't
join that multicast group because we didn't know whether we'd need or not.
applyMulticast6(caglobals.ip.m6.fd, &IPv6MulticastAddressLnk, interface);
//applyMulticast6(caglobals.ip.m6.fd, &IPv6MulticastAddressRlm,
interface);
We just need to flip the switch and we'll begin listening on the right group.
I'm not sure what other changes are required -- I can't tell where the
CA_SCOPE_RLM flag would get set. So this requires some testing to make it work.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4447 bytes
Desc: not available
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150826/7262c3e2/attachment.p7s>
