Re: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00

[Ryuji Wakikawa <ryuji.wakikawa at gmail.com>]

Hi
On 2008/11/17, at 13:39, Arnaud Ebalard wrote:

> Hi,
>
> Ryuji Wakikawa <ryuji.wakikawa at gmail.com> writes:
>
> > True, IPsec/IKE are painful part when implementing Mobile IPv6.
> > There is another reason that is supporting the feature of returning
> > home.
> > We need a lot of special codes for returning home (including SAD/SPD
> > parts).
> >
> >   (9)  The way that the IPsec code sits in the usual kernel, and the
> >        access mechanisms for the SA database, are not very convenient
> >        for use by straightforward implementations of Mobile IPv6.
> >        Unusual calling sequences and parameter passing seems to be
> >        required on many platforms.
> >
> > I repeated this several time, but we should have informational RFC
> > something like
> > http://tools.ietf.org/html/draft-sugimoto-mip6-pfkey-migrate-04
> > This is very useful document for implementators.
>
> Linux 2.6.28 will be fully compliant with a followup document I wrote
> (SADB_X_EXT_PACKET part removed and replaced by KMADDRESS extension, a
> more simple and efficient mechanism). Those changes have been merged
> mainline:
>
> http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced- 
> migrate-00
>
> I am currently handling integration of  associated patches in racoon
> (for MIGRATE/KMADDRESS support). I also have interactions w/ people  
> from
> strongSwan project which are currently implementing what is  
> specified in
> my draft for Charon, the IKEv2 daemon.
>
> Patches for UMIP (will see that w/ Sugimoto-san) are also
> available. Information is available on http://natisbad.org/MIPv6/
>
> Comments appreciated if you have some time to review those pages and  
> the
> draft.

good to know there are progresses on the spec and impl.

Shinta sent us a patch of PF_KEY modification for SHISA (BSD-MIP  
implementation) a long time ago.
I don't remember if we merge the patch or not.. Keiichi may answer this.

> > I have another concern.
> > Whenever MN moves, MN needs IKE signaling if the feature of K-bit is
> > not supported.
> > We have to consider the movement latency including IKE/MIP signaling
> > exchange.
> > We do not optimize the IKE part. As a result, MN may not do fast
> > handover...
>
> When using IKE, an *unmodified* IKE daemon is not able to negotiate  
> the
> initial transport mode SA so K-bit does not make sense in the end. You
> need to have a MIPv6-modified IKE implementation to bootstrap. Please,
> take a look at previous draft. I have already raised the issue
> (Sebastien Decugis has even written a draft on the topic.)

I personally don't care if IKE is modified or not for MIP.
My personal comment is that "it's better to mandate K-bit always set  
to 1."

regards,
ryuji



regards,
ryuji

> Cheers,
>
> a+

_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext