RE: ULE Extension Header Thoughts

["William StanisLaus" <williams@calsoft.co.in>]

Please see my response inlined...

> -----Original Message-----
> From: owner-ipdvb@erg.abdn.ac.uk 
> [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Hilmar Linder
> Sent: Monday, June 28, 2004 12:58 PM
> To: ip-dvb@erg.abdn.ac.uk
> Subject: ULE Extension Header Thoughts
> 
> 
> when thinking about the extension headers for ULE we left several 
> questions untouched in the first draft. Therefore, I would 
> like the list 
> to comment on the following items:
> 
> o) Should we define the chaining mechanism: All mandatory extension 
> headers MUST/SHOULD be inserted by the encapsulator prior to any 
> extension headers in order to optimize receiver processing. A 
> receiver 
> is such able to discard a SNDU whose mandatory extension 
> header is not 
> supported or is to be rejected without having to investigate and 
> eventually process optional extension headers beforehand.

William> It MUST be implemented all mandatory headers before any
optional headers and actual data. Since at any cost if mandatory header
is not supported/implemented the receiver MUST drop the SNDU. Inserting
optional header before mandatory headers will give room to unnecessary
processing.

> o) Does it make sense to define the header types 0x002 and 0x003 as 
> mandatory encryption header (section 2.1). As different encryptions 
> require different extension headers we should probably only 
> define that
> the next-layer-header types should be larger than 0x001 and 
> smaller than
> 0x0100.

William> Needs clarification, encryption header is a more generic term,
what type of encryption MUST be defined with the type field. Can be more
than one encryption technique used. But i wonder, no point in using
predefined encryption technique without key exchange. Hope this is the
next level of discussion. How and What type of encryption we are going
to support

> o) How many different encryption schemes do we expect to support with 
> the ULE extension headers? Is the type range allocated 
> suffciently large?

William> Should be suffciently large.

> o) Will we see different odd/even encryption header types for 
> IPv4 and 
> IPv6 traffic?

William> the encryption we are discussing here is L2 encryption and
nothing to do with the IPv4 and IPv6 i believe, Since there are well
defined encryptions already available for L3 i.e. IPSEC.


> 
> Any other thoughts?
> 

William> my personnel opinion on extension header is just to give room
to support future extensions, and we should keep as minimal as possible
ULE for better performance and bring down the overhead of exhastive
conditional checks.

> -Hilmar Linder
> (co-editor)
> 

Best Regards,
William.

> 
> -------------- ipdvb list -------------------
> To unsubscribe from the ipdvb list :-
> Email majordomo@erg.abdn.ac.uk with the words
> unsubscribe ipdvb
> in the body of the message.
> http://www.erg.abdn.ac.uk/ipdvb/
> ---------------------------------------------
> 

-------------- ipdvb list -------------------
To unsubscribe from the ipdvb list :-
Email majordomo@erg.abdn.ac.uk with the words
unsubscribe ipdvb
in the body of the message.
http://www.erg.abdn.ac.uk/ipdvb/
---------------------------------------------