[support] Re: [Dsmip] Implementation of UMIP and Dyanamic key estabilishment through IKEv2 in IPV4-only network

[satya sahu]

Hi Arnaud ,

Thank You so much  for your thoughts and sharing of informations .

Regarding the solutions :


Solution -A :
You are right ,it's a work around but i have tried for  testing purpose.
Here is the obeservation.

I am able to made changes in KMADDRESS part in strongswan. So that when it
receives the migrate message for v6 mappedv4 address , it will  just unmap
to real v4 adress and schedules to the IKE job. There is no ipv6 header in
IKE_SA_INIT ,it is form MN's IPV4 home address to HomeAgentV4 address. It is
successfully received by HA and following IKE_AUTH messages are also
exchanged successfully between HA and MN ,but some how the SAs are not
created , i suspected this due the incorrect XFRM policy and template in HA
and MN(Still seaches for ipv6 address).

------So still digging into that part.

Solution B :

Yes it will be better a Approach , I have already pointed out some functions
and code part to be changed . I have also started the code changes. I will
inform you regarding the fucntions and files to be touched during this
exercise. also need your comments and feedback.



--Any suggestions and pointers will be highly Appreciable.


On Fri, Feb 27, 2009 at 8:42 PM, Arnaud Ebalard <arno at natisbad.org> wrote:

> Hi,
>
> satya sahu <satya0675 at gmail.com> writes:
>
> > *Solution B*
> >
> >           I was thinking of making the following code change in mip6d
> when
> > MN move to FL(IPv4):
> >
> > 1.      Enhanced the behavior of KMADDRESS to support IPv4 address also.
> I
> > have already verified that strongswan support KMADDRESS having IPv4 or
> IPv6
> > addresses.
> >
> > 2.      Insert corresponding IPv4 xfrm policies and templates to the
> kernel.
> > Which is missing currently. Current implementation push v6-mapped-v4
> policy
> > to the kernel when MN moves to FL(IPv4).
> >
> > Changes will be made when the new CoA address is v6-mapped-v4. The
> following
> > functions may be affected to support the above requirement.
> >
> > Ø       _mn_trns_update
> >
> > Ø       _mn_tnl_update
> >
> > Ø       _mn_tnl_pol_mod
> >
> > Ø       xfrm_sendmigrate
> >
> > Ø       ...And some more to be identified...
> >
> > Kindly let me know if I am thinking on the right direction to fix the
> issue.
> > I will appreciate if you can send me some more pointers which Solution I
> > should go for.
>
> Solution A looks like a workaround. Solution B is IMHO the way to
> go. Regarding the list of function, it looks like a good start.
>
> If you manage to implement and test your ideas, I'd be interested by some
> feedback that could be integrated in:
>
> http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00
>
> Cheers,
>
> a+
>
> ps: you may find some material on http://natisbad.org/MIPv6/ and in the
>    repo here: http://hg.natisbad.org/migrate2_patches_umip_nemo/
>
> _______________________________________________
> Dsmip mailing list
> Dsmip at ml.nautilus6.org
> http://ml.nautilus6.org/mailman/listinfo/dsmip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.nautilus6.org/pipermail/support/attachments/20090302/66e79ff4/attachment-0002.htm