Subject: ULE Extension Header Thoughts

From: Hilmar Linder <[email-masked]>
Date: Mon, 28 Jun 2004 09:27:38 +0200

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.
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.
o) How many different encryption schemes do we expect to support with 
the ULE extension headers? Is the type range allocated suffciently large?
o) Will we see different odd/even encryption header types for IPv4 and 
IPv6 traffic?

Any other thoughts?

-Hilmar Linder
(co-editor)

-------------- ipdvb list -------------------
To unsubscribe from the ipdvb list :-
Email [email-masked] with the words
unsubscribe ipdvb
in the body of the message.
http://www.erg.abdn.ac.uk/ipdvb/
---------------------------------------------

---

From: "William StanisLaus" <[email-masked]>
Date: Tue, 29 Jun 2004 20:56:05 +0530

Please see my response inlined...

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hilmar Linder
> Sent: Monday, June 28, 2004 12:58 PM
> To: [email-masked]
> Subject: ULE Extension Header Thoughts
> 
> 

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.

> the next-layer-header types should be larger than 0x001 and 

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

> the ULE extension headers? Is the type range allocated 

William> Should be suffciently large.

> o) Will we see different odd/even encryption header types for 

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.

> (co-editor)

Best Regards,
William.

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 30 Jun 2004 09:28:56 +0100

Hilmar, William, other people on the list, can I make some comments as a 
WG Chair and solict feedbacok from the list:

I'm first trying to work out if there are potential issues when the 
ordering of Mandatory Extension headers could result in reduced 
inter-operability (i.e. Where a receiver will fail/behave unexpectedly 
because of the ordering).

>>eventually process optional extension headers beforehand.

Agreed, if an operator chose to do this it could be a waste of 
processing resources to process extension headers belonging to a PDU, 
and then ultimately discard that PDU. If the first extension was always 
present in all SNDUs however, teh cost of processing could be reduced by 
pattern-matching the headers (as in TCP header prediction), so the cost 
need not always be as much as it seems.

> optional header before mandatory headers will give room to unnecessary

Normally when the IETF mandates MUST be implemented, it implies an 
interoperability issue. A good ethos is for receivers to liberal in what 
they receive (that way we avoid painful discoveries when new uses appear).

* I wonder though if this is really an inter-working issue, or purely an
optimisation that a gateway could use, in the same way the NPA address 
can be used as a pre-filter or not, depending on topology, bandwidth 
cost, etc. In other words, what breaks if we allow arbitrary ordering?

* Another issue is what we could we loose by requiring specific ordering?

If there are potential issues where this results in reduced
inter-operability (i.e. Where a receiver will fail because of the 
ordering) then I think we should specify - If there are only 
performance-related issues then we could identify these, but I'd urge 
being liberal in what the Receiver should accept - 
implementers/operators can still optimise Receivers for the most common 
code-path.

<snip>

Gorry
ipdvb WG Chair