Ron, > 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.
don't get me wrong, I'm also in support of this work. ;-) but if we go down this slippery slope. where do we draw the line? I do know of filtering routers that look at the L7 headers. and I'm sure there are those that inspect the payload as well. do we arbitrary choose to stop at the L4 header? as Karl pointed out, what do we do with the ESP header? do you define which part of the ESP header that must be included in the first fragment? or does this mean that a packet with ESP MUST NOT be fragmented? are there other headers where what consist of the "entire ipv6 header chain" is unclear? > 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? yes, I think that would help. Best regards, Ole > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
