Hi Anders, Thanks for your detail comments -- those are quite useful!
Please see in-line. -----Original Message----- From: Anders Brandt [mailto:[email protected]] Sent: Monday, September 02, 2013 2:44 AM To: [email protected]; Pascal Thubert (pthubert); Samita Chakrabarti; Erik Nordmark (nordmark); [email protected] Subject: draft-chakrabarti-nordmark-6man-efficient-nd - Proposing new use case "Set-and-forget off-line network" [cross-posting 6man / 6lo] Samita Chakrabarti et al, Great draft which addresses important issues for low-power wireless network technologies. After reading the draft, it seems to me that you would benefit adding one more use case - and addressing the derived requirement(s). Proposed use case: ------- A.7. Set-and-forget off-line networks Home control modules designed for networked environments may be deployed in very simple settings like garden path lighting controlled by wireless light and motion sensors. Once the network has been created and sensors have been associated with the light modules, the installer takes away the configuration tool which was used to set up the network. Most likely a ULA prefix is used, since multiple hops may be needed. None of the sensors and light modules has the capability of handing out fresh prefixes. Thus, for a set-and-forget style off-line network to work, the nodes must be able to operate forever without trying to refresh its address registration. In another instance of an off-line network, a key-fob style remote control is paired to a few lamp modules. The controller creates its own small off-line network. The controller is not only battery powered and sleeping. It is far away in its owner's pocket. Address registration is not possible. The manufacturer of the lamp module wants to sell exactly the same lamp module to large network deployments where address registration is used. Since this class of devices provide no local configuration interface, the behaviour needs to be controlled via some sort of auto-configuration. ------- (end of proposed use case) [SC>] ===> Added. One solution could be to introduce a special interpretation of registration lifetime 0xFFFF as infinite and stating that default routers SHOULD NOT advertise this value. Such an approach would resemble existing text in RFC4861: Valid Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xffffffff) represents infinity. The Valid Lifetime is also used by [ADDRCONF]. The authors may have other preferred solutions? [SC>] ===> As discussed off-line that , the valid lifetime for the prefix is still valid and the ARO lifetime applies to the registration lifetime. We have discussed some of the issues with allowing permanent registration (especially with NCE cache entries). So at this point we have agreed to keep the ARO lifetime range as it is. Best regards, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
