Subject: Re: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-01.txt

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 1 Mar 2008 23:44:45 +1000

> I have another question related to the TLV use. Since BU are 
 > supposed to 
 > always be sent in vanilla UDP encapsulation (this is a MUST in the 
 > draft) we are likely to receive both TLV-encapsulated and 
 > vanilla-encapsulated packets on the same port, right?
 > 
 > Therefore my question is: how the receiver is supposed to 
 > guess how to 
 > decapsulate the packet? Does it rely on the first bytes 
 > following the 
 > UDP header, to recognize IP or IPv6 packet? In this case we 
 > don't need 
 > the TLV or TV at all, do we?
 > 
 > Thank you for any answer on this... (even telling that my 
 > question makes 
 > no sense if I missed something, thanks!)

=> No your question makes sense. The receiver will have to rely on the Type
byte to tell the difference since in many cases the receiver will not know
whether the payload contains the TLV or not as you said even if a BU was
already sent. 

Hesham

 > 
 > Best regards,
 > Sebastien
 > 
 > 
 > Hesham Soliman a écrit :
 > > Personally, I *strongly* prefer not to touch this. I would 
 > have preferred
 > > not to have this silly TLV in the first place but to put 
 > it in context (this
 > > is my personal opionion of course) this field will not be 
 > used by MN. The
 > > reason IMO for having this was NETLMM people wanting to 
 > encapsulate things
 > > like GRE... For those cases saving 3 bytes is not really worth it. 
 > > 
 > > Hesham 
 > > 
 > >  > -----Original Message-----
 > >  > From: Teco Boot [mailto:[email-masked]] 
 > >  > Sent: Wednesday, February 27, 2008 7:07 PM
 > >  > To: 'Hesham Soliman'
 > >  > Cc: [email-masked]
 > >  > Subject: RE: [MEXT] I-D 
 > >  > ACTION:draft-ietf-mext-nemo-v4traversal-01.txt
 > >  > 
 > >  > >>>> TLV-header UDP encapsulation:
 > >  > >  > And is a length field of only one octet not a little 
 > >  > bit to small?
 > >  > >  > Encapsulated payload could exceed 255 octets.
 > >  > > 
 > >  > > => Yes, good catch, it's a bug, it should be 2 bytes.
 > >  > Are we sure we need the payload length field?
 > >  > UDP length is already available, and this new length 
 > field is simply
 > >  > UDP_Length - 12.
 > >  > 
 > >  > I do not prefer a mandatory 32-bit alignment carrying only a 
 > >  > single octet
 > >  > type field.
 > >  > What about type dependent padding?
 > >  > 
 > >  > For types with 32-bit alignment:
 > >  > 
 > >  >        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      |                   Reserved           
 > >  >          |
 > >  >       
 > >  > 
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > >  > 
 > >  > For types with low overhead:
 > >  >        
 > >  >        0 1 2 3 4 5 6 7 
 > >  >       +-+-+-+-+-+-+-+-+
 > >  >       |     Type      |
 > >  >       +-+-+-+-+-+-+-+-+
 > >  > 
 > >  > Teco.
 > >  > 
 > >  > 
 > >  > 
 > > 
 > > 
 > > _______________________________________________
 > > MEXT mailing list
 > > [email-masked]
 > > https://www.ietf.org/mailman/listinfo/mext
 > > 
 > 
 > -- 
 > Sebastien Decugis
 > http://www.nautilus6.org
 > _______________________________________________
 > MEXT mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/mext
 > 

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