Re: [Mip6] [issue94] fixing encapsulation mechanism in IPv4 network
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mip6] [issue94] fixing encapsulation mechanism in IPv4 network



Hello,

On 2007/03/21, at 1:59, Vijay Devarapalli wrote:

Keiichi SHIMA wrote:
New submission from Keiichi SHIMA <keiichi at iijlab.net>:
The current DSMIPv6 draft specifies two encapsulation formats, one is the IPv4 encap format, the other is UDPv4 encap format. The default encapsulation format is the IPv4 format, and if the HA explicitly specifies to change the encapsulation format to the UDPv4 format if there is a NAT box between the HA and the MN. Because of this specification, HA and MN have to support both encapsulation formats and have to change the format dynamically, that may increase the hurdle for implementors and may cause complexity in interoperability.

If I remember right, this was among the first few issues that were discussed in the design team. Some folks did suggest turning on UDP all the time when the access network is IPv4. But this is an overhead in case there is no NAT. Thats why we have a NAT detection mechanism in the DS-MIPv6. UDP encapsulation is turned on only if a NAT is detected. My preference is to still go with this.

I agree that using UDP has an overhead compared to a simple IP encapsulation format.


My question came from the idea that 'which is the major environments for IPv4? A NATed environment or a global IPv4 environment?' If most of the IPv4 networks that the mobile terminals connect to is NATed networks, then simply using UDP seems better to me.

But my perspective may be wrong. I want to hear some more opinions from who are interested in DSMIPv6 operation.

---
Keiichi SHIMA
IIJ Research Laboratory <keiichi at iijlab.net>
WIDE Project <shima at wide.ad.jp>



Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Mip6 mailing list
Mip6 at ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.