Jari,
[I'm ccing IPng for the interpretation of RFC 2460 ]
> If one reads the last paragraph of page 6 one can read it two ways:
>
> Either: "With one exception, extension headers are not examined or
> processed
> by any node along a packet's delivery path.." meaning hop-by-hop options
> header. Then, "If, as a result of processing a header, a node is required
> to proceed to the next header, but the Next Header value in the current
> header is unrecognized..", could mean: possible existence of hop-by-hop
> options header "must be examined" resulting in that after IPv6 header
> the "required to proceed" condition is met, but the Next Header is
> unknown,
> this would result in the discarding rule. There is, luckily, even in this
> case, the possibility to ignore this.
>
> Or: That there is not h-b-h next header invalidates the "must be examined"
> rule and one could skip an unknown number (just forwarding the packet
> irrespective what garbage there is at its end). I hope this could be
> the correct interpretation since the h-b-h must immediately follow the
> IPv6 header. Unless someone challenges this order rule with a new header,
> or someone comes with a new h-b-h option requiring proceeding to something
> else, this could hopefully be the "right interpretation".
>
=> I believe so, but you could also check that on IPng.
Anyhow, the new header value we've been discussing is
a new DST-opt header which will only be processed by
the end nodes.
If a router is forwarding a packet and the first header below
the IPv6 header is not h-b-h then I see no reason for
it to recognise/process this header.
> If someone observes the former, it would risk that there are boxes that
> drop packets with new unknown next headers. In the latter there would not
> be. Our boxes do the right thing, but can it be guaranteed so do others?
>
=> It sounds like the others are faulty if they're doing the
opposite. Faulty boxes do exist I suppose, we can't design
protocols around them. Having said that, I haven't seen anyone
saying they implemented their boxes in this way.
> This could have been clearer in the text saying that routers must ignore
> next headers other than h-b-h. But, this would not be the first RFC in
> routing where "well-known" implementation guidelines help interpret the
> actual text.
>
>
Hesham
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
