Experimental Bits
=================

This section is a work in progress. The ideas aren't fully formed yet and
certainly don't reflect any approved direction for Thread.

`NetworkName` and UTF-8
-----------------------

At its core, `NetworkName` is treated as an opaque 128-bit identifier.
This is at odds with it being treated as a UTF-8 string. Without
certain precautions being taken, various types of attacks are
possible. See [STRINGPREP][RFC3454] for more details. As such, this
document defines specific transforms to use when transforming a
string into a `NetworkName` and vise-versa:

Converting a string into a `NetworkName`:

 1. Apply STRINGPREP parts B, C, and D.
 2. Unescape any characters in the string.
 3. Check the length of the resulting string and reject if the
    resulting string is longer than 16 bytes.
 4. Zero-fill the string to 16 bytes in length.

Converting a `NetworkName` to a string:

 1. Convert the `NetworkName` to a string using the following steps:
    a. Treat the string as zero terminated, appending a zero if necessary.
    b. Escape control characters up to the first zero.
 2. Test for canonicity by converting the string back to a 16-byte
    `NetworkName` using the procedure outlined above. If the test
    passes, return the string.
 3. If the string failed the test, convert the `NetworkName` to a
    canonical string using the following steps:
    a. Remove all tailing zeros from the `NetworkName`.
    b. Escape all non-printable ASCII control characters, including zero.

Character escaping uses the simple URL "percent" escaping.

It is not expected that constrained implementations will perform
these conversions. If a constrained implementation must convert a
network name to a human-readable string, it may always assume that
the canonicity tests fails and fall back to an ASCII string with
escaped characters.


Insecure MAC mode
-----------------

If `NetworkXPANID` is set to the 8-byte non-zero-terminated ASCII string
`"insecure"`, then the `ThreadAdminPassword` is assumed to be a zero-length
string. In this mode:

 * Any device may join the network, much like an unsecured WiFi network.
 * MAC layer security is to operate only in message authentication mode,
   meaning the contents of the packets will not be encrypted.
 * Nodes will not respond to administrative requests to change thread
   network parameters like the network name.

This mode is primarily useful as a debugging tool. It may be wise to disable
support for such a mode in release builds.

Routing Protocol
----------------

Thread uses RPL for intra-mesh routing. There is always at least
one DODAG, which is the mesh-local DODAG.

NOTE: The DODAG root is unrelated to the `ThreadLeader`.

The mesh-local DODAG uses the prefix `FE40::/10`(Prefix suggestion.
Actual prefix may be different). This prefix MUST NOT be routed
outside of the logical mesh. Routes to other networks may be
advertised using DIO messages or by establishing another RPL instance.
Thread router nodes must support at least two RPL instances. Doing
this will make intra-mesh communications much more robust in the
face of possibly dynamic IPv6 prefixes.

Again, `FE40::/64` is not routable outside of the mesh! It is used
only within the mesh, much like `FE80::/10` is not routable and
only used for link-local communications. The multicast prefix for
mesh-local hosts is `FF03::1`.

## Mesh-local DODAG Root selection ##

TBD

### Mesh-local DODAG Root failure scenario ##

TBD

## RPL Settings ##

 * MOP: 0x3
 * DODAGPreference: 0