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

From: Keiichi SHIMA <[email-masked]>
Date: Fri, 2 Mar 2007 10:50:21 +0900

Hi,

On 2007/02/28, at 11:57, Hesham Soliman wrote:

> => 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.
>

FYI, our BSD based implementation (SHISA) processes all MIPv6 signal  
messages in user space programs.

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: Vijay Devarapalli <[email-masked]>
Date: Thu, 01 Mar 2007 18:38:58 -0800

Hesham Soliman wrote:
> 
>  > 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.
> 
> => 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.

The first MIPv6 implementation I had worked on (Nokia Research
Center) was all in the kernel. Turned out to be a bad idea.
Causes too much code bloat in the kernel. Has a lot of issues
too. It actually makes sense to implement it in the user space
and only have the tunneling part, Home Address option, routing
header addition and few other things in the kernel.

Vijay

> 
> I'd love to hear what others think, I think it's a good point to discuss. 
> 
> Hesham
> 
>  > 
>  > Thanks
>  > Sri
>  > 
>  > 
>  > On Wed, 28 Feb 2007, Hesham Soliman wrote:
>  > 
>  > > 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
>  > > >
>  > > >
>  > > > 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>
>  > > > _________________________________________________
>  > > >

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Mar 2007 22:00:35 +0100

Hesham Soliman wrote:
> 
>> 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.
> 
> => 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.
> 

Sorry for replying late on this.  I got redirected here from NETLMM WG.

I deal with three types of mip6 implementations: kernel exclusively, app
exclusively and mixed.

My initial was kernel-exclusively.  Then people said it's complicated.
Then some app-exclusively mip6 implementation had some advantages but
turned out to not send BU upon handover because the ongoing audio/video
stream was taking too many resources.

Just to say that it depends on what kind of environment one works on, 
and that there _are_ advantages to do kernel only.

Alex

>> Thanks 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
>>>> 
>>>> 
>>>> 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
>>>> 
>>>> 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]> 
>>>> _______________________________________________ Mip6 mailing
>>>> list [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
>>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________ Mip6 mailing list
>>>  [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
>>> 
>> 
> 
> 
> 
> _______________________________________________ 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 
______________________________________________________________________