Subject: Re:

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 11 Oct 2001 19:04:26 +1000

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-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Thu, 11 Oct 2001 19:40:47 +0700

Date:        Thu, 11 Oct 2001 19:04:26 +1000
    From:        "Hesham Soliman (EPA)" <[email-masked]>
    Message-ID:  <[email-masked]>

  | > If one reads the last paragraph of page 6 one can read it two ways:

I think way too much is being read into that.   Routers are only
required to look at the IPv6 header, and the HbH options header if
one exists.   Only if there is some problem with one of those will
a router drop a packet (for IPv6 reasons, as distinct from congestion,
no route, etc).

The
	If, as a result of processing a header, a node is required
	to proceed to the next header, ...

means "where a node has to look at the next header", then if its type
is unknown, the packet has to be dropped.   A router never looks at the
next header, unless its type is "HbH" - in which case (one hopes) it
isn't an unknown type.

Note: it doesn't say that if you process a header and it contains an
unknown next header field you drop the packet - only if you have to
process the next header, and its type (which comes from the current
header) is unknown.  Routers never have to process the next header...

ie: your reply is right, the question is assuming things the text doesn't say.

kre