lkml.org 
[lkml]   [2002]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHSET] Mobile IPv6 for 2.5.43
    On Thu, Oct 31, 2002 at 05:44:42PM +0900, Noriaki Takamiya wrote:
    > Hi,

    Hello Takamiya,

    > Please note that we're preparing for checking to what extent this
    > patch is compliant to the Internet draft of MIPv6.

    May I ask with what? We ran all the TAHI tests last month at ETSI
    IPv6 Plugtest, and know pretty much were we stand. And with all due
    respect to TAHI, who checks that the test suites conform to the spec?

    > (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?

    If MIPv6 is compiled as module, and is not loaded, those macros
    protect against calling non-existant code. HA and MN do not need to
    be compiled statically, if that is what you are implying. You must
    first select CN support, which decides module or static.

    > Rather, how about using sysctl and so on to switch the
    > functionality?

    No. Users want to be able to have only one of the capabilities loaded
    at one time (i.e. CN, CN+MN or CN+HA). When you compile e.g. CN,
    there is no HA or MN support compiled in, so the sysctl makes no sense.

    > (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().

    No. We did this back in Draft 15, when all the mobility stuff was
    destination options. Mobility Header is not an extension header, but
    rather a final protocol. Only Home Address Option is an extension
    header and is handled in ipv6/exthdrs.c. What is the problem with
    this?

    > (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?

    Yes, this will be done. But that was merged yesterday, and we are
    only humans :)

    > (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]

    Right. We haven't changed the IPv6 code to support the third
    destination option header placement (after RH, before frag/AH/ESP),
    and since it introduces no compatibility problems with any other
    implementation we've tested with, it has not been a priority.

    Regards,

    Antti

    --
    Antti J. Tuominen, Gyldenintie 8A 11, 00200 Helsinki, Finland.
    Research assistant, Institute of Digital Communications at HUT
    work: ajtuomin@tml.hut.fi; home: tuominen@iki.fi

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:30    [W:0.023 / U:29.352 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site