[support] Re: [Dsmip] NAT Traversal is not working as mentioned in DSMIPv6 draft

[manish Jamwal]

Hi Nassim
Yes, I have tried ipv6-in-ipv4 with the below Xfrm policy and state. But the
ping6 packet is not going out of MH(Mobile Host) and showing the below
message:

>From 2001:a:b:1::1 icmp_seq=0 Time exceeded: Hop limt

*Information related to Xfrm Policy/State*
*Xfrm Policy:*
src 2001:a:b::1/128 dst ::/0
        dir out priority 2
        tmpl    src c0a8:4f9:: dst ::
                proto 166 spi 0x00000000 reqid 0 mode tunnel
                level use

*Xfrm State:
*src 192.168.4.249 dst 0.0.0.0
        proto 166 spi 0x00000000 reqid 0 mode tunnel
        replay-window 0
        encap (not implemented yet!)
        sel src 2001:a:b::1/128 dst ::/0

*Note:*
      a. 192.168.4.249 ----> IPv4 CoA of egress interface of MH.
      b.  2001:a:b::1/128  -------> IPv6 HoA of MH.

Does the above Xfrm policy/State correct for UPD Encapsulation of data
packets in IPv4 FL?

Regards
Manish Jamwal

On Tue, Mar 3, 2009 at 11:48 AM, Nassim Kobeissy
<nassim.kobeissy at gmail.com>wrote:

> Hi Manish,
> Sorry for this late reply.
> You are trying to encapsulate ipv4-in-ipv4, right? I am not sure that it
> works. you have to go back to the udp encapsulation patch in the kernel to
> verify the implementation. Did you try ipv6-in-ipv4?
>
> Best regards.
> Nassim
>
>
> On Tue, Mar 3, 2009 at 6:23 AM, manish Jamwal <manish.jamwal at gmail.com>wrote:
>
>> Hi Nassim
>>
>> Thanks for your reply. As per your previous mail, I added the Xfrm policy
>> and states to UDP encapsulate data packets, when MN moves to IPv4 FL. But
>> still the data packets are not getting udp encapsulated. For verification, I
>> am pinging egress interface of HA. The added Xfrm policy and state on MN
>> side is mentioned below. If I am adding wrong policy and state,
>> please correct me on this....
>>
>>
>> *Xfrm Policy on MN:*
>> src 192.168.4.249/32 dst 0.0.0.0/0 proto udp
>>         dir out priority 2
>>         tmpl    src 192.168.4.249 dst 0.0.0.0
>>                 proto 166 spi 0x00000000 reqid 0 mode tunnel
>>                 level use
>>
>> *Xfrm State on MN:*
>> src 192.168.4.249 dst 0.0.0.0
>>         proto 166 spi 0x00000000 reqid 0 mode tunnel
>>         replay-window 0
>>         encap (not implemented yet!)
>>         sel src ::/0 dst ::/0
>>
>> Regards
>> Manish Jamwal
>>
>>
>>   On Sat, Feb 28, 2009 at 1:06 PM, Nassim Kobeissy <
>> nassim.kobeissy at gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, Feb 28, 2009 at 8:17 AM, manish Jamwal <manish.jamwal at gmail.com>wrote:
>>>
>>>> Hi Nassim/Kien
>>>> Thanks for your response. I called the below mentioned functions in ha.c
>>>> file for adding and deleting xfrm policy and states for UDP encapsulation of
>>>> BA packets. Now I am able to see UDP encapsulated BU/BA packets.
>>>>
>>>> For adding policy and state, called *udpencap_encap_out_traffic_**
>>>> start()* from *ha_recv_bu_worker()* routine inside the  *if
>>>> (out.nat_info) {} *condition.
>>>> For deleting policy and state, called *udpencap_encap_out_traffic_end()
>>>> * from* home_cleanup()* routine.
>>>>
>>>> Currently data packets are not getting UDP encapsulated in IPv4 network,
>>>> when NAT is detected. But it is mentioned in draft
>>>> (draft-ietf-mext-nemo-v4traversal-08.txt) that *if NAT device was in
>>>> the path and the NAT detection optionis included in the binding
>>>> acknowledgement.  The binding acknowledgement, and all future packets,
>>>> should then encapsulated in UDP and IPv4.*  I need some pointers on how
>>>> to UDP encapsulated data packets, when NAT is detected.
>>>>
>>>> Can we add xfrm policy/state for data packets? Currently according to my
>>>> understanding this is not looking feasible, as we do not know the dst
>>>> endpoints before hand to add policy/state.  At present I am not focusing on
>>>> multiple CoA addresses behind NAT device.
>>>>
>>>> Regards
>>>> Manish Jamwal
>>>>
>>>>
>>>> Hi Manish,
>>> I had the intention to implement complete NAT Traversal, however, i am no
>>> more working on the project. I had some ideas but they need to be tested and
>>> validated.
>>>
>>> You can/must add policies/states for data packets. you can specify the
>>> source address in the selector with any destination for outgoing packets on
>>> the MN for example. For packets send by the MN it self, this MUST be easy.
>>> For MNN packets, i am not sure... The MN ( MR in this case) receives the MNN
>>> packets then it sends them into the UDP "tunnel". If you solve this
>>> FORWARDING stuff, then, i imagine that next steps are easier.
>>> Same holds for HA. you set the source address to any and the destination
>>> to the MN/MR and the list of MNNs. (policy/state by dst address)
>>>
>>> Best regards
>>> Nassim
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.nautilus6.org/pipermail/support/attachments/20090303/47a57be8/attachment-0002.htm