Ole,
I am supporting this draft because the community has become accustomed to
stateless firewalls on routers. These stateless firewalls are capable of
filtering based upon information gleaned from both the IPv6 and L4 header.
When a stateless firewall encounters an IPv6 datagram in which the IPv6 header
and L4 header don't appear in the first fragment, it can't make an informed
filtering decision on any fragment. However, if there is a guarantee that the
IPv6 header and the L4 header are in the first fragment, it can at least make
an informed decision regarding that fragment.
Would the draft be more acceptable if we stated this as the motivation and
removed references to NAT64?
Ron
> -----Original Message-----
> From: Ole Troan [mailto:o...@cisco.com]
> Sent: Wednesday, February 06, 2013 4:51 PM
> To: Ronald Bonica
> Cc: Fernando Gont; 6man-cha...@tools.ietf.org; ipv6@ietf.org
> Subject: Re: Moving forward draft-ietf-6man-oversized-header chain?
>
> while we are on the topic, and you made me re-read the document.
>
> section 4:
> issues with terminology. call a device that walks the extension header
> chain something else than a router.
> rfc2460 definition of a router; "extension headers are not examined or
> processed by any node along a packet's delivery path".
> a switch in my book doesn't look at L3 headers.
> use "middlebox" or "filtering router"?
>
> section 3:
> is the main justification for this work to make NAT64s function better?
> if so that might be a little short-sighted, by the time we've updated
> IPv6 implementations... perhaps use a different example than NAT64?
>
> section 5:
> restricting the header chain seems like an incomplete solution. doesn't
> a middlebox need to reassembly fragments anyway, to deal with mis-
> ordered fragments?
> at least at some point I thought BSD sent fragmented packets by sending
> the last fragment first.
>
> with a more idealist hat on:
> that extension headers are hard to parse, some consider a feature of
> IPv6.
> a feature that tries to protect the end to end Internet, i.e. that we
> can deploy new transport protocols and extension headers without
> upgrading all intermediate boxes. changing the IPv6 protocol for a
> flawed design (aka middleboxes), is that wise?
> might as well just deprecate IP fragmentation. (which I would be in
> favour of).
>
> and don't get me wrong, I can't imagine any use case for an extension
> header chain longer than 1280 bytes either.
>
> cheers,
> Ole
>
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
