Subject: [netlmm] UDP encap or not for PBU/PBA

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 21 Aug 2008 23:30:06 +0900

Hi all,

sorry for my delay.
Let me summarize the discussion, though Sri seems to agree on the  
proposal;-)

Issue was "Is it really necessary to mandate UDP encap for every PBU/ 
PBA."

There are three solutions discussed on the list so far.

1. Forcing UDP encap
We force UDP encapsulation for every PBU/PBA. The current spec is  
defined so.

2. The use of UDP encap for the initial PBU. If no NAT is detected,  
PBU/PBA is carried with IPv4-IPv6 tunnel (no UDP).

3. If NAT is not deployed between MAG and LMA, operators can prohibit  
UDP encapsulation for every PBU/PBA.
     We need a configuration flag for this.

I am fine with both 1 and 2, but not 3.
As Sri mentioned, it is not good idea to open two sockets (UDP port  
and raw sock) for the same control messages.
Whenever MN changes the attachment, a new MAG will send an initial PBU  
with UDP encap.
As an implementation point of view,  two ways to receive the same  
control signaling might not be worth to pay here.
The size of UDP header is just 8 bytes.

 From my understanding, an implementation of raw-IPv4 PBU/PBA is a bit  
tricky.
An application daemon cannot distinguish between MNs' data traffic and  
signaling (PBU/PBA).
You can save 8 bytes, but it comes with extra processing overhead to  
check all IPv4-IPv6 packets (if you use raw sock.)
Anyway, let's not discuss implementation here.

If Vijay is fine (you propose the solution-2?!),
we will define a new flag(s) to turn on/off UDP encap for PBU/PBA.

regards,
ryuji

_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 21 Aug 2008 08:09:47 -0700 (PDT)

Hi Ryuji,

I think there is enough interest for native IPv4 encap for control
messages, we can probably add that mode. If implementations want
to handle that, what ever way, put their control plane in the
kernel, add IPv6/IPv4 transitional support or open raw sockets
to move all IPv6 packets to the user space, is probably their
issue. So far as I see it, the consensus is to support that mode
and if you also agree, we can add support for that mode in the
next rev and close this thread. So, the config flag will ensure
there is no UDP encap for data or control messages and this should
keep the folks happy for their usecase.

Regards
Sri

On Thu, 21 Aug 2008, Ryuji Wakikawa wrote:

> Hi all,
>
> sorry for my delay.
> Let me summarize the discussion, though Sri seems to agree on the proposal;-)
>
> Issue was "Is it really necessary to mandate UDP encap for every PBU/PBA."
>
> We force UDP encapsulation for every PBU/PBA. The current spec is defined so.
>
> 2. The use of UDP encap for the initial PBU. If no NAT is detected, PBU/PBA 
> is carried with IPv4-IPv6 tunnel (no UDP).
>
> 3. If NAT is not deployed between MAG and LMA, operators can prohibit UDP 
> encapsulation for every PBU/PBA.
> As Sri mentioned, it is not good idea to open two sockets (UDP port and raw 
> sock) for the same control messages.
> Whenever MN changes the attachment, a new MAG will send an initial PBU with 
> UDP encap.
> As an implementation point of view,  two ways to receive the same control 
> signaling might not be worth to pay here.
> From my understanding, an implementation of raw-IPv4 PBU/PBA is a bit tricky.
> You can save 8 bytes, but it comes with extra processing overhead to check 
> all IPv4-IPv6 packets (if you use raw sock.)

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 22 Aug 2008 00:41:50 +0900

Sri

I am fine with that.
This is what I agreed in the previous mail.

ryuji

On 2008/08/22, at 0:09, Sri Gundavelli wrote:

>> 3. If NAT is not deployed between MAG and LMA, operators can  
>> prohibit UDP encapsulation for every PBU/PBA.
>> Whenever MN changes the attachment, a new MAG will send an initial  
>> PBU with UDP encap.
>> An application daemon cannot distinguish between MNs' data traffic  
>> and signaling (PBU/PBA).
>> You can save 8 bytes, but it comes with extra processing overhead  
>> to check all IPv4-IPv6 packets (if you use raw sock.)