Hi,
> In my opinion a protocol running logically directly above the link-layer,
> such as IP (adaptation layers like 6LoWPAN may exist in between) will
> typically require information about the interface that received the
packet.
> (The same is true for other layers, e.g. UDP cannot work without
information
> from the IP header.)
While your statement is true for UDP the argument does not hold for IP in
my opinion. UDP (or TCP) need the IP information, because IP otherwise
doesn't know how to send the packet, since UDP does not handle this kind of
information. IP on the other hand has ARP/NDP to resolve an IP address into
link-layer information. Furthermore, as far as we discussed so far we
talked only about reception of a packet and there this information is only
important for routing protocols and IP-internal stuff (and for the most
part only the non-address related information from these header, like the
interface identifier and the link-layer metrics). In these cases the
information is provided for natural interfaces. Pseudo-interfaces as you
define them usually are not handled by these kind of operation in a
sensible way so packets from those can just ignore packets without a netif
header.
> Not in all cases a physical interface may be involved, but for those cases
> there should typically be a pseudo-interface. The only case, where we do
not
> have a pseudo-interface right now (as far as I know) is the loopback case.
> In my opinion, it is - for efficiency reasons - completely okay not to
> provide a loopback device in GNRC, but I still don't see a reason why a
> netif header indicating a pseudo interface should do any harm here.
> Implementation detail:
> So far, KERNEL_PID_UNDEF is used as identifier in my proposal, but we
could
> also define the PID of the IPv6 thread as loopback device identifier.
Well unless you want to send all IPv6 packets to the loopback to the IPv6
thread this would require an additional check anyways.
> Finally, I think asserting a present netif header makes the code easier,
> because one does not have to cover exception cases and provide different
> branches for netif-header-is-present and netif-header-is-NOT-present.
I have the complete opposite impression: Currently the check for a netif
header is AFAIK only present at the point of your patch. So we have a
little bit more complex code at this point (where the complexity is only as
far as a `assert(netif)` vs `if(netif) { iface = netif->iface } else {iface
= KERNEL_PID_UNDEF}`), while anything else that is a pseudo-interface now
needs to prepend a netif header to the packet.
Cheers,
Martine
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
