Subject: Re: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-cpe-simple-security-15.txt

From: RJ Atkinson <[email-masked]>
Date: Thu, 14 Oct 2010 18:11:03 -0400

Earlier today, James Woodyatt wrote:
> I'm not sure Mr. Arkko's original comment about 
> "new extension header, new transport protocols, etc. 
> would not work through [IPv6 simple security]" is 
> strictly correct.  

I certainly hope it isn't entirely correct.

I can think of 2 relevant examples of new IPv6 options:
	RFC-5570
	draft-rja-ilnp-nonce-06.txt

One would hope packets with either or both of those options
would be handled properly -- i.e. as per RFC-2460, Section 
4.2.  

If someone really thinks that the quoted claim at top is true, 
I'd love to be educated why/how/when it is true ?

> We can expect that new transport protocols will be tracked 
> with generic state records comprising source address and 
> next header value.  Assuming I-D.ietf-6man-exthdr proceeds 
> to standard, we can also expect the same for all new standard 
> extension headers.

It has never been clear to me what extension header might
exist in future that is neither a hop-by-hop option nor
a Destination Option.  Formats for defining new options for
either of those seem quite clearly defined in RFC-2460.

So I've been a bit confused what actual problem I-D.ietf-6man-exthdr
is trying to solve; perhaps it is merely cluelessness
on my part that the problem/issue isn't obvious to me, 
but education on what problem that I-D solves also 
would be welcome.

Yours,

Ran

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 Oct 2010 03:29:06 -0300

> but education on what problem that I-D solves also 

Without having read the aforementioned I-D, my take/guess is that it
aims at defining a common syntax for new extension headers.

The "current problem" is that extension headers do not have a common
syntax (TLV-like), and hence a middlebox could possibly *not* be able to
parse the whole header chain to e.g. be able to do deep packet inspection.

That said, I agree with you that one would expect that we already have
enough extension headers such that, in the event you need to define a
new option, there's no need to define a new extension header to include
that option. -- i.e., this issues shouldn't be a problem in practice.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1