On 4/16/10 4:28 PM, james woodyatt wrote:
> On Apr 16, 2010, at 12:43, Suresh Krishnan wrote:
>> 
>> As James chimed in, we let the draft expire because there was no
>> clear consensus in the WG as to the need to define new extension
>> headers. We have addressed all the comments received from the WG in
>> the last version the draft. We can refresh the draft and request
>> the chairs for adoption, provided we see somebody trying to define
>> or seeing a need to define a new extension header.
> 
> In other words, it appears to be the sense of the working group that
> the presence of an unrecognized next header value currently precludes
> the possibility of identifying whether there is an unrecognized
> extension header interposed between the IPv6 header and the
> upper-layer transport header.  It's important to note that
> 'unrecognized' does not mean 'undefined' here-- it just means
> 'undefined when the packet analyzer was made' which is not precisely
> the same thing.
> 
> Going back to Mr. Carpenter's message about extracting the 5-tuple
> from IPv6 packets, it seems pretty clear that the logical consequence
> of the above is that we have only two real alternatives available: A)
> strongly recommend that all hosts set the flow label, so that we can
> use the 3-tuple {source address, dest address, flow label}, B) change
> our mind about whether we need a standard format for generic
> extension headers, so that we have some hope of always being able to
> find the 5-tuple even when we cannot process the interposing
> extension header.
> 
> For the record, I *strongly* prefer option A over option B.  On the
> other hand, if we go with option B, then that will allow greater
> flexibility in using RFC 3692 protocol numbers in the face of
> stateful packet filters like those described in
> I-D.ietf-v6ops-cpe-simple-security, making them less of an
> interference than they would otherwise be.

Option A also allows for the handling of encrypted packets where the
transport layer port numbers can't be found regardless.

Regards,
Brian H.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to