On Thu, Aug 30, 2007 at 08:04:24AM +1200, Brian E Carpenter wrote:
> On 2007-08-30 02:08, Thomas Narten wrote:
> >Sorry to interrupt, but I'd suggest that working on a new RH design is
> >mostly a waste of time at this point.
> >
> >Can we please _first_ identify a user/customer for a proposed RH,
>
> I agree. A use case draft should be the first step.
>
> Incidentally, RFC 2460 is clear that unknown headers should cause the
> packet to be dropped, so the transition strategy is tricky in any case.
>
> 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 by the node, it should discard the packet and send an
> ICMP Parameter Problem message to the source of the packet, with an
> ICMP Code value of 1 ("unrecognized Next Header type encountered")
> and the ICMP Pointer field containing the offset of the unrecognized
> value within the original packet.
Yes, but this would only be the node addressed by the IPv6 header - or
do I read this wrongly? So the core of the network is not affected either
way (unless explicit filtering is implemented somewhere), and only
routers of end networks that wish to participate in, say, a future RH4
routing would need to upgrade the software.
-is
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
