Hi,
This is Takamiya, a member of USAGI Project.
Your work is very cool. However, we believe there are several
issues on direction / design and behavior in your implementation.
Please note that we're preparing for checking to what extent this
patch is compliant to the Internet draft of MIPv6.
So we may comment other things later.
(1) About MIPV6CALLFUNC and MIPV6CALLPROC
It is reasonable to use these macros for modularized
functions. But the current your implementation needs to select
HA or MN when compiling the kernel. So, it doesn't seems to be
needed this macros, and the real function may be called
directly. How about this?
Rather, how about using sysctl and so on to switch the
functionality?
(2) Avoiding Netfilter Hooks
In your imprementation HA uses netfilter to intercept packets
sent to MN. We think it is costy so we have a suggestion to
use FIB structure to forward packets to MN. Bacause we think
forwarding packets from HA to MN is FORWARDING, not FILTERING.
We think the kernel maintainers may prefer such a manner using
FIB structure for forwarding.
(3) Binding Cache
We think it is reasonable way to use FIB structure to holding
Binding Cache Entries if you us FIB structure for forwarding
packets from HA to MN as we suggested (4).
(4) Processing Mobility Header
How about using ip6_txoptions and hdrproc_lst?
Because Mobility header is an extension header, we think it is
reasonable way to handle it in ipv6_parse_exthdrs().
(5) How about using CryptoAPI?
CryptoAPI is merged to mainline.
We believe we can use the CryptoAPI for caluculating cookies
of RR. How do you think about this?
(6) Order of HAO and Routing header
When MN acts also as CN, the order doesn't seems to be
compliant to ID-18 in the implementation. The order will be
the following:
[IPv6][HAO][RT2]
I-D says:
[IPv6][RT2][HAO]
(7) Source Address Selection of MN
When host acts as MN, your implementation always select HoA as the
source address. The source address should be a CoA.
Regards,
-- Noriaki Takamiya - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:52 EST