Subject: Re: [Mip6] I-D ACTION:draft-ietf-mip6-nemo-v4traversal-04.txt

From: Keiichi SHIMA <[email-masked]>
Date: Sat, 17 Mar 2007 21:27:39 +0900

Hi,

On 2007/03/17, at 18:35, Hesham Soliman wrote:

>> Why do we need to have multiple IPv4 encapsulation formats?
>> I wonder
>> why we cannot simply use UDP encapsulation always.  What is the
>> benefit of providing multiple encapsulation mechanisms?
>
> => One obvious answer is: saving bandwidth.

OK.  I understand there are some people requires to save the bytes,  
even if the bytes are just 8.

>> If we can just specify the UDP encapsulation mechanism only, then
>> both HA and MN don't have to implement IPv4 in IPv6 encapsulating
>> process for DSMIPv6 and don't need to implement the selection
>> mechanism to decide which mechanism to use.  Since IPv4 NAT
>> is almost
>> everywhere,
>
> => But encapsulating IPv4 in IPv6 has nothing to do with IPv4 NATs,  
> It's a
> scenario where the access network supports IPv6 and therefore you  
> only use
> IPv6 for the signalling. I don't see why we should add a UDP  
> header. If the
> tradeoff is between making an implementer's life easy by doing less  
> work Vs
> reducing bandwidth, I hope we would choose to reduce redundant  
> bits. It
> seems strange to add redundant bits just to make sure the implementer
> doesn't have to implement IPv4 in IPv6 tunnels.

Hum, I think I was not very successful to explain my idea.  I was not  
suggesting to use the UDP encap mode to save the bits.

In the current specification, a mobile node implementer must  
implement both the IPv6 in IPv4 encap mode and the IPv6 in UDPv4  
encap mode.  The mobile node uses the IPv4 encap mode normally, but  
it has to switch to the UDP encap mode, if its home agent suggests to  
use the UDP encapsulation mode.  I think if we can specify just one  
encap mode for the DSMIPv6 protocol, it helps implementors and also  
it will reduce the number of the interop test cases of the spec.

I don't have any preference between the IPv4 encap mode and the UDPv4  
encap mode, as long as it works even if the node is behind a NAT  
box.  I just wanted to simplify the operation by removing dynamic  
decision of encap mechanisms.

Regards,
---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
WIDE Project <[email-masked]>

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 18 Mar 2007 14:43:09 +0100

Keiichi SHIMA wrote:
>>> Why do we need to have multiple IPv4 encapsulation formats? I
>>> wonder why we cannot simply use UDP encapsulation always.  What
>>> is the benefit of providing multiple encapsulation mechanisms?
>> 
>>>  both HA and MN don't have to implement IPv4 in IPv6
>>> encapsulating process for DSMIPv6 and don't need to implement the
>>> selection mechanism to decide which mechanism to use.  Since IPv4
>>> NAT is almost everywhere,
>> 
>>  It's a scenario where the access network supports IPv6 and
>> therefore you only use IPv6 for the signalling. I don't see why we
>> should add a UDP header. If the tradeoff is between making an
>> implementer's life easy by doing less work Vs reducing bandwidth, I
>> hope we would choose to reduce redundant bits. It seems strange to
>> add redundant bits just to make sure the implementer doesn't have
>> to implement IPv4 in IPv6 tunnels.
> 

I agree decision of encap mechanism is difficult to implement, deals 
with different data structures from different spaces.  I think there's 
more to this discussion.

 From protocol standpoint, it sounds strange to use UDP if not behind NAT.

It also sounds strange to use _only_ UDP even if behind NAT.  Some 
NAT/FWs allow IP-in-IP and don't allow UDP.

As implementer, IMHO, if all DS-MIPv6 control messages were exclusively 
MH, or exclusively UDP, then it would be better, IMHO, for simplifying 
implementation.

I mean I could live with control being MH/UDP and transport with 
IP-in-IP (not UDP).  Either of MH or UDP for control, but only one.

Not sure I'm clear...

Alex

> 
> Regards, --- Keiichi SHIMA IIJ Research Laboratory
> <[email-masked]> WIDE Project <[email-masked]>
> 
> 
> 
> 
> _______________________________________________ Mip6 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________