Subject: Re: Taking RFC2460 (base IPv6) spec to full standard - issues outstanding

From: Mohacsi Janos <[email-masked]>
Date: Wed, 5 Oct 2005 11:27:58 +0200 (CEST)

On Wed, 21 Sep 2005, Elwyn Davies wrote:

> Dear IPv6 WG Chairs,
> I previously sent this mail to the list at the time of the wg meeting in 
> Paris
> but there was no response.  Has any decision been taken on how to move 
> forward
> with the IPv6 suite going towards full standard?  I believe these items 
> should
> be looked at before RFC2460 goes forward.
>
> ==================================================
> Resent message from 2 August 2005:
>
> In the course of doing the security overview draft in v6ops, we identified a
> number of issues that appear to be errata or issues with the main IPv6 
> standard.
> These should potentially be fixed up as 2460 goes to full standard:
>
> Points for full standard;
> ?	(non-)Processing of Type 0 routing headers in hosts
> ?	(non-)Processing of Type 2 routing headers in routers

This is necessary to be defined.

> ?	Processing Extension Headers in Middleboxes -
>   o	words about where headers are inspected need to be relaxed
>   o	words about processing headers out of order need to be relaxed
>   o	should intermediate nodes be allowed to discard packets with unknown
>        extension headers?

I think this can be relaxed: Any internmediate system can delete any 
packet if policy dictates. This should not be very strict, but somehow 
force the IPv6 conformance.

> ?	Requiring that new extension headers use TLV format (and maybe 
> putting
>        the length into the fragmentation header) - to simplify skipping 
> headers
>        in middleboxes

This would be a good decision.

> ?	Constraining new hop-by-hop options both as to number and function -
>        h-by-h should be designed either for simple fast path processing 
> (like
>        jumbo packets) or to explicitly cause a packet to be dumped to the 
> slow
>        path (like router alert).

It would be good if such a distinction could be done.

> ?	Fragment reassembly algorithm - should explicitly forbid overlapped
>        fragments and possibly require that non-final fragments are (say) at
>        least 1024 bytes.

According the RFC2460 the minimal MTU must be 1280. So Each fragments - 
except the last fragment packet should be at least 1280. - this is 
implicitly written in RFC2460 spec: "The lengths of the fragments must be 
chosen such that the resulting fragment packets fit within the MTU of the 
path to the packets' destination(s)." I understand this, that each 
fragment packet should be no smaller than MTU, which is at least 1280.

I think it is wise to make it more explicit.

This my opinion only.

Regards,
 	Janos Mohacsi

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------