Subject: Re: [conex] Fwd: Hop-by-Hop Extension Header processed in Slow Path?

From: Alex Burr <[email-masked]>
Date: Fri, 4 Feb 2011 04:23:35 -0800 (PST)

marcelo bagnulo braun <marcelo at it.uc3m.es> wrote:
> I recommend people to take a look at this thread going on on 6man.
> It seems apparent from this thread that we either manage to  code the conex 
>info in some bits in the main IPv6 header or conex is out  of luck. 
>

Maybe this is a dumb question, but why isn't a destination option a possibility 
for conex? It would seem they are a perfect fit.

Alex

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 7 Feb 2011 16:46:54 -0500

Hi Alex,

> for conex? It would seem they are a perfect fit.

According to the base IPv6 spec Destination options are to be processed 
only by the ultimate receiver of the datagram (the one in the 
destination address field). Doing so in an intermediate node would 
violate the spec.

Thanks
Suresh

---

From: John Leslie <[email-masked]>
Date: Mon, 7 Feb 2011 19:29:13 -0500

>>> I recommend people to take a look at this thread going on on 6man.

   I strongly recommend not merely looking, but participating. The
"Hop-by-Hop Extension Header processed in Slow Path" is actively
discussing (well, "actively" by 6MAN standards) whether it makes
sense to define a header that isn't Hop-by-Hop but is intended to
be acted upon by "middleboxes".

>> Maybe this is a dumb question, but why isn't a destination option a 
>> possibility for conex? It would seem they are a perfect fit.

   Hardly "perfect"...

> destination address field). Doing so in an intermediate node would 

   I feel unable to say whether this would "violate" any spec. I'm
pretty sure some folks active in 6MAN would disagree with that statement
(and others would just as strongly agree).

   The intent seems to be clear at the time of writing RFC 2460 that
routers along the way wouldn't take the time to process a Destination
Options header unless the packet were addressed to them. Nonetheless,
I didn't read that as a prohibition: least of all a prohibition of
such a header being examined by middleboxes. (And, of course, 2460
isn't the whole story.)

   But that question cannot be resolved here. 6MAN is the WG charged
to address such issues.

   I'm not going to go into details here, but I recommend reviewing
my presentation to ICCRG in November, at

http://pfld.net/2010/slides/iccrg-leslie.pdf

and actively participating on 6MAN, whether by stating what you'd
like ConEx to be able to do with an intermediate class of options
or simply by asking a question.

--
John Leslie <[email-masked]>