This is a quick note to clarify an issue mentioned in Thiago's notes. " John suggested having an option for "IP dual stack", one for IPv4 only and one for IPv6 only."
I'm sure Thiago understands this is not what I suggest or propose. "Dual stack" is a current term of art in the IPv6 community referring to the best means of managing the transition from IPv4 to IPv6. The first Google response to "IPv6 dual stack" is http://www.networkworld.com/article/2285078/tech-primers/ipv6--dual-stack-where-you-can--tunnel-where-you-must.html . The 'dual stack' approach refers to allowing the application to support two network stacks, both at the *socket layer only*. This can be done two ways: One socket that binds to a special IPv6 address that includes an embedded reference to an IPv4 address. Two sockets that bind to IPv6 and IPv4, respectively. I chose the second approach because it provides more flexibility for managing interfaces, at the cost of one socket, which is cheap. When done properly (see caethernetserver.c:: CAReceiveHandler in ca-ipv6) there is almost no extra code, and the rest of the application sees only one result. The dual stack approach allows us full IPv6 support with automatic fallback to IPv4 when needed, with a single binary. A working example of this approach is available in ca-ipv6. John Light Intel Opensource Technology Center OIC Development -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Friday, March 20, 2015 11:58 AM To: Kesavan, Vijay S Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] IPv6 changes to IoTivity On Friday 20 March 2015 11:00:43 Kesavan, Vijay S wrote: > Thiago, Hi Vijay > With regards to your comments, perhaps it will help clarifying some of > the initial goals of CA. CA, which sits below the resource model > layer, is intended to: Indeed, clarification seems to be in order. Is there any list of requirements or use-cases that CA is trying to solve? It would help incredibly if this were documented either on the wiki or in a JIRA ticket. > 1. support and manage multiple adaptors types - Ethernet, WiFi, BT, > BLE initially (as opposed to single IP adaptor support that currently > exists in master branch); Sounds like a misfeature to split Ethernet and WiFi. Everyone I've talked to for the past two months has been saying the distinction is artificial and creates additional complexity that isn't necessary. See also John's email saying it's neither necessary nor sufficient. This distinction should go away and we should have "IP" only. In addition: - John suggested having an option for "IP dual stack", one for IPv4 only and one for IPv6 only. I disagree, especially after the discussion with St?phane. It should be "IP" only and the stack auto-selects the most appropriate. - BT and BLE should refer to the OIC profile over BT, not for OIC-over-IP- over-Bluetooth. > 2. abstract the resource model from the transport protocol so that if > CoAP is replaced by a different protocol the resource layer should not > change; Agreed, that is important. That is in fact necessary for the OIC profile for Bluetooth, since it's not IP-based at all, so CoAP there makes no sense. We may be able to use some of the payload format, but that's about it. > 3. support multiple adaptors of the same type Agreed, that's mandatory. > The current CA code mainly focusses on item 1, some limited support > for 2, and no support for 3. > > The current APIs only support one adaptor of each adaptor type, a > starting step for APIs as well as implementation, and not a long term > solution. It should be noted that there are no current plans for CA > to have "smarts" to know that resources are reachable via multiple > adaptors and manage selection/switching between adaptors. For this > reason, and also because existing Iotivity services asked that the > adaptor type be exposed, current APIs include adaptor-type information. When you say "no current plans", are you including "no work expected before 1.0"? As long as CA is not part of the IoTivity API that users can use, we can fix it later. Otherwise, it's a fatal flaw and blocks 1.0. Why did the IoTivity services require the adaptor type? That's totally surprising to me. Given all of this discussion... sorry to be blunt, but do we need CA at all? It seems to be going in the wrong direction. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
