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
Vijay,
[snip]
> 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.
Honestly, based on our small MIP deployment experiments & experience
the NAT traversal has been kind of secondary (but a good additional)
feature. The greatest value of UDP encapsulation has been the firewall
traversal.
Cheers,
Jouni
> > Isn't it possible to fix the encapsulation format to one of
> these mechanisms described in the draft?
>
> If we are to pick only one encapsulation format, we clearly
> can't pick "IPv4 encap format" (as you called it) because it
> may not work through a NAT. It has to be UDP encapsulation always.
>
> Vijay
>
> >
> > ----------
> > category: Technical
> > draft: draft-ietf-mip6-nemo-v4traversal
> > messages: 338
> > nosy: keiichi
> > priority: May fix
> > status: No discussion
> > title: fixing encapsulation mechanism in IPv4 network
> >
> > _________________________________________________
> > Mip6 issue tracker <tracker-mip6 at mip4.org>
> > <http://www.mip4.org/issues/tracker/mip6/issue94>
> > _________________________________________________
> >
> > _______________________________________________
> > Mip6 mailing list
> > Mip6 at ietf.org
> > https://www1.ietf.org/mailman/listinfo/mip6
>
>
> _______________________________________________
> Mip6 mailing list
> Mip6 at ietf.org
> https://www1.ietf.org/mailman/listinfo/mip6
>
_______________________________________________
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.