Nalini Elkins wrote: > But the reality of the situation is that much of the Internet appears > to be running where > > "n is an arbitrary number picked out of the air by a vendor" > > Or rather > > "multiple arbitrary numbers"! > > Yes? Correct.
There is a non null union between the set of IETF standards and the set of operational configurations of the various networks that form the Internet; but neither is a proper subset of the other. That's nothing new. > > Thanks, > > Nalini Elkins > Inside Products, Inc. > (831) 659-8360 > www.insidethestack.com > > ------------------------------------------------------------------------ > *From:* Ray Hunter <v6...@globis.net> > *To:* Nalini Elkins <nalini.elk...@insidethestack.com> > *Cc:* Brian E Carpenter <brian.e.carpen...@gmail.com>; 6man > <ipv6@ietf.org>; Fernando Gont <fg...@si6networks.com>; > "vishwas.man...@hp.com" <vishwas.man...@hp.com> > *Sent:* Thursday, June 6, 2013 9:42 AM > *Subject:* Re: draft-ietf-6man-oversized-header-chain-02 (was Re: Re: > draft-ietf-6man-ext-transmit-01) > > IMVHO interpreting the text of the current drafts. > > > Nalini Elkins <mailto:nalini.elk...@insidethestack.com > <mailto:nalini.elk...@insidethestack.com>> > > 6 June 2013 18:20 > > So, if we are talking about the MTU of the local egress interface, > > then since, I believe, the minimum MTU size for IPv6 is 1,280, then > > all devices should be prepared to examine up to 1,280 bytes to get the > > L4 header? > Not quite. > > AFAICS > > 1. All parsing engines should be able to parse at least 1280 bytes to > cover the minimum IPv6 MTU. > > 2. If all the local interfaces are Ethernet, and have an MTU set of > 1500, the parsing engine on that box should be able to parse a full > Ethernet frame of 1500 bytes of payload..... and so on for devices > supporting links with larger MTUs, all the way up to jumbograms (if > supported on that device). > > 3. draft-ietf-6man-ext-transmit gives the option of not parsing > extension headers at all on high speed routers (only the hop by hop > option is supposed to be parsed by routers on the path). But neither > this draft, nor any other IETF draft that I know of, gives an option for > parsing an IPv6 header chain "just for the first n bytes", where n is an > arbitrary number picked out of the air by a vendor, whether that be 53, > 256 or 1280. > > regards, > RayH > > > > Thanks, > > > > Nalini Elkins > > Inside Products, Inc. > > (831) 659-8360 > > www.insidethestack.com <http://www.insidethestack.com/> > > > > ------------------------------------------------------------------------ > > *From:* Ray Hunter <v6...@globis.net <mailto:v6...@globis.net>> > > *To:* Nalini Elkins <nalini.elk...@insidethestack.com > <mailto:nalini.elk...@insidethestack.com>> > > *Cc:* Brian E Carpenter <brian.e.carpen...@gmail.com > <mailto:brian.e.carpen...@gmail.com>>; 6man > > <ipv6@ietf.org <mailto:ipv6@ietf.org>>; Fernando Gont > <fg...@si6networks.com <mailto:fg...@si6networks.com>>; > > vishwas.man...@hp.com <mailto:vishwas.man...@hp.com> > > *Sent:* Thursday, June 6, 2013 9:14 AM > > *Subject:* draft-ietf-6man-oversized-header-chain-02 (was Re: Re: > > draft-ietf-6man-ext-transmit-01) > > > > Nalini Elkins wrote: > > > >>> Some tricky and potentially malicious cases will be avoided by > > > forbidding very long chains of extension headers that need to be > > > >>> fragmented [I-D.ietf-6man-oversized-header-chain]. > > > > > > > > I wonder if this is the place to define "very long"? > > > > > > >> I guess those two words can be deleted - the issue is only that the > > > header chain gets fragmented at all. The full discussion is in the > > > cited draft, of course. > > > > > > I know the draft that you have cited and they do not define "long" > > > either. There has been quite a bit of discussion about what "long" > > > means and IMHO somewhere, someone needs to take some kind of > > > reasonable stand. > > > > > Actually IMHO ietf-6man-oversized-header-chain DOES define "unusually > > long" very accurately. > > > > I-D.ietf-6man-oversized-header-chain requires that "the first fragment > > of a fragmented datagram is required to contain the entire IPv6 header > > chain" > > > > So in other words, any packet parsing engine should be prepared to > > examine an entire single frame up to the MTU of the local egress > > interface, but should not be expected to maintain any state across > > multiple fragments. > > > > We might also benefit operationally from setting an additional limit on > > the length of the hop hop option header, which is theoretically meant to > > be processed by routers along the path. However, my guess is that is > > well beyond the author's original intentions for > > draft-ietf-6man-oversized-header-chain-02, which was more focussed on > > firewalls. > > > > > > > > >>The IETF hasn't done much about firewalls at all. This > > > search produces far more expired drafts than anything else: > > > >> > > > https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit= > <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=> > > > <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit= > <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=>> > > > > > > <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit= > <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=> > > > <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit= > <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=>>> > > > > > > The reason I asked is because I think defining RFCs or rules for > > > firewalls is a really good thing to do but if the vendors are not in > > > the habit of having to be compliant, then why would they pay attention > > > to this draft that we are discussing? I actually think maybe an RFC > > > which explicitly talks about firewalls is probably a good thing to do. > > > Now, getting vendors to comply... > > > > > > Thanks, > > > > > > Nalini Elkins > > > Inside Products, Inc. > > > (831) 659-8360 > > > www.insidethestack.com <http://www.insidethestack.com/> > > > > > > > > > > > Ray Hunter <mailto:v6...@globis.net <mailto:v6...@globis.net>> > > 6 June 2013 18:14 > > Nalini Elkins wrote: > >>>>> Some tricky and potentially malicious cases will be avoided by > >> forbidding very long chains of extension headers that need to be > >>>>> fragmented [I-D.ietf-6man-oversized-header-chain]. > >>> I wonder if this is the place to define "very long"? > >>>> I guess those two words can be deleted - the issue is only that the > >> header chain gets fragmented at all. The full discussion is in the > >> cited draft, of course. > >> > >> I know the draft that you have cited and they do not define "long" > >> either. There has been quite a bit of discussion about what "long" > >> means and IMHO somewhere, someone needs to take some kind of > >> reasonable stand. > >> > > Actually IMHO ietf-6man-oversized-header-chain DOES define "unusually > > long" very accurately. > > > > I-D.ietf-6man-oversized-header-chain requires that "the first fragment > > of a fragmented datagram is required to contain the entire IPv6 header > > chain" > > > > So in other words, any packet parsing engine should be prepared to > > examine an entire single frame up to the MTU of the local egress > > interface, but should not be expected to maintain any state across > > multiple fragments. > > > > We might also benefit operationally from setting an additional limit on > > the length of the hop hop option header, which is theoretically meant to > > be processed by routers along the path. However, my guess is that is > > well beyond the author's original intentions for > > draft-ietf-6man-oversized-header-chain-02, which was more focussed on > > firewalls. > > > >>>> The IETF hasn't done much about firewalls at all. This > >> search produces far more expired drafts than anything else: > >>>> > https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit= > <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=> > >> > <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit= > <https://datatracker.ietf.org/doc/search/?name=firewalls&rfcs=on&activeDrafts=on&oldDrafts=on&search_submit=>> > >> > >> The reason I asked is because I think defining RFCs or rules for > >> firewalls is a really good thing to do but if the vendors are not in > >> the habit of having to be compliant, then why would they pay attention > >> to this draft that we are discussing? I actually think maybe an RFC > >> which explicitly talks about firewalls is probably a good thing to do. > >> Now, getting vendors to comply... > >> > >> Thanks, > >> > >> Nalini Elkins > >> Inside Products, Inc. > >> (831) 659-8360 > >> www.insidethestack.com > >> > > > > ------------------------------------------------------------------------ > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
