Inline.... > -----Original Message----- > From: Ole Troan [mailto:otr...@employees.org] > Sent: Thursday, February 07, 2013 5:19 AM > To: Ronald Bonica > Cc: 6man-cha...@tools.ietf.org; Fernando Gont; ipv6@ietf.org > Subject: Re: Moving forward draft-ietf-6man-oversized-header chain? > > 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?
Clearly, we have to draw the line somewhere. I think that it is reasonable 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? The document needs to make a special exception for encrypted payloads. In that case, the ESP header must begin on the first fragment, but need not end on the first fragment. Does this sound reasonable? > > > 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. I will work with Fernando on this. > > 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 --------------------------------------------------------------------
