Subject: [Mip6] [issue93] Payload Qualifiers when using IPv4-UDP transport for both IPv4 and IPv6 payloads

From: Sri Gundavelli <[email-masked]>
Date: Tue, 27 Feb 2007 21:38:08 +0000

New submission from Sri Gundavelli <[email-masked]>:

Reference to section 4.3.1 and 4.4.1.

For the IPv4 transport and with NAT in path, the opaque
encapsulation mode of IPv4-UDP for both IPv4 and IPv6
payload packets i.e IPv6/IPv4-UDP or IPv4/IPv4-UDP is being
recommended by the draft. With out a payload qualifier
in the UDP header, I wonder how the tunnel peer handles
the packet after decapsulation ? How would it know, if it
is an IPv4 payload packet or an IPv6 packet ? Do you expect
some packet inspection after decapsulation ?

One option is to have thin header such as the MIP Tunnel
Data Message from RFC-3519, as suggested by Kent Leung.

MIP Tunnel Data Message
   
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Next Header  |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We want a quick resolution on this. draft-sgundave-mip6-proxymip6-02.txt
has normative reference to the DSMIP6 spec.

Thanks
Sri

----------
category: Technical
draft: draft-ietf-mip6-nemo-v4traversal
messages: 330
nosy: sri
priority: Must fix
status: No discussion
title: Payload Qualifiers when using IPv4-UDP transport for both IPv4 and IPv6 payloads

_________________________________________________
Mip6 issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/mip6/issue93>
_________________________________________________

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 28 Feb 2007 13:14:10 +1100

Hi Sri, 

Why can't the receiver do the switch on the version field? 
I mean, how does the receiver of any encapsulated packet know the version of
the inner header?

Hesham 

 > -----Original Message-----
 > From: Sri Gundavelli [mailto:[email-masked]] 
 > Sent: Wednesday, February 28, 2007 8:38 AM
 > To: [email-masked]
 > Subject: [Mip6] [issue93] Payload Qualifiers when using 
 > IPv4-UDP transportfor both IPv4 and IPv6 payloads
 > 
 >

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 27 Feb 2007 18:52:39 -0800 (PST)

Hi Hesham,

Version field can be used to distinguish that. But, when
a packet is encapsulated in any application header,
it needs to be wrapped in a TLV format. Example: RFC-3519.
If there is no wrapper, application would not even know the
size of that packet, or the type of the packet, unless its
derived from the IP header. That adds some complexity w.r.t
the way applications use the socket interface ..options etc.
Having a wrapper would be usefull. The normal encapsulation
modes in L3 such as IP/IP, IPv6/IPv6, GRE, all have the type
field and so when we wrap a packet in L4, we need an identifier
some where, IMO.

Thanks
Sri

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 28 Feb 2007 13:57:56 +1100

> field and so when we wrap a packet in L4, we need an identifier

=> I know the following question is not necessarily the crux of your issue
but does anyone implement MIPv6 as an application? I know it's possible to
do that but no one seemed to make that choice to my knowledge, but I could
be wrong.

I'd love to hear what others think, I think it's a good point to discuss. 

Hesham

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 27 Feb 2007 19:28:39 -0800 (PST)

> do that but no one seemed to make that choice to my knowledge, but I could

It depends on the OS and the available tunneling semantics ...etc
But, on a normal unix derivative, I'd implement it as:

- Application for control layer
- Kernel module for data handling
   or a simple route setup

So, for normal encap modes, IP/IP ..etc, this will be handled
in the kernel mode, as the filter rule such as in netfilter is
a simple ptype. But, when the packet is in L4 header and if we
have to look for version field, not sure, if we can specify
such complex filter rules and so it needs to received as an
application payload and routed properly.

But, it all depends. Some guy might implement it in a better way.

Sri

---

From: "Hugo Santos" <[email-masked]>
Date: Wed, 28 Feb 2007 05:29:40 +0000

Hi,

> I'd love to hear what others think, I think it's a good point to discuss.

 To a point, yes. In my Linux-based approach, all of the MIPv6's
control ended up in an user-space process for extra flexibility. Only
data transformation, including binding cache handling for RO and IPSec
(already existing) ended up in the kernel.

  Hugo