[Int-area] Re: IP Parcels and Advanced Jumbos (AJs)

Content changes are not allowed in AUTH48, but We just concluded WG last call.On Sep 27, 2024, at 8:43 AM, Templin (US), Fred L wrote: > UDP options cannot currently be used for still larger sizes   Actually, there is an easy fix for this which can be added to the queue for AUTH48.   Fred

Re: [Int-area] tunneling and recursion (was: Re: New Version Notification for draft-li-int-aggregation-00.txt)

In the example I gave, I was equating GRE *to* UDP, not saying it ran over UDP, though it can (port 4754, per RFC 8086). Joe > On Feb 28, 2022, at 10:15 PM, Dino Farinacci wrote: > > There is no UDP port number assigned for GRE because it does not run over > UDP. It runs DIRECTLY over IP. Ch

Re: [Int-area] New Version Notification for draft-li-int-aggregation-00.txt

> On Feb 25, 2022, at 3:07 PM, Dino Farinacci wrote: > >  >> >> We use all three in the Internet (longest prefix, ARP/LISP, and RIP/OSPF, >> respectively). > > But we haven't used ML. Wonder what people think about that? Machine learning? As in the failed DARPA Intelligent Nets effort? I

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

-dtn-ltpfrag/ > > From: to...@strayalpha.com [mailto:to...@strayalpha.com] > Sent: Friday, December 03, 2021 11:37 AM > To: Templin (US), Fred L > Cc: Dino Farinacci ; int-area@ietf.org; Dirk Trossen > > Subject: Re: Side meeting follow-up: What exact features do we want

Re: [Int-area] Tunnels and Fragmentation

> On Apr 17, 2020, at 10:29 AM, Templin (US), Fred L > wrote: > > Also, what about intarea-tunnels? That one shows up as expired, but shouldn't > we > dust it off for publication too (after updating to accommodate new findings)? I responded to that on Thurs. Joe ___

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

EH isn't a HBH option or extension. Joe On 2020-02-27 15:06, Fernando Gont wrote: > On 27/2/20 19:52, Joe Touch wrote: > >> FWIW - there are separable issues here: >> >> - whether an IP header (or parts thereof) should be changed in transit >> >&g

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On 2020-02-27 15:10, Robert Raszuk wrote: >> It does matter whether it happens at the IP source (origin host, tunnel >> ingress, etc.) or on the path of that header. > It happens on tunnel ingress and tunnel egress nodes (egress = node listed in > DA of the packet). Ingress can create whatever

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

y RFC2473. > > Its subtle detail, but fundamental one to this entire context/discussion. > > Kind regards, > R. > > On Thu, Feb 27, 2020 at 11:54 PM Joe Touch wrote: > >> FWIW - there are separable issues here: >> >> - whether an IP header (or parts th

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On 2020-02-27 15:00, Tom Herbert wrote: > On Thu, Feb 27, 2020 at 2:52 PM Joe Touch wrote: > >> FWIW - there are separable issues here: >> >> - whether an IP header (or parts thereof) should be changed in transit >> >> AFAICT, the answer has always been

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On 2020-02-27 14:50, Fernando Gont wrote: > ... > I'm not being purist. I'm just arguing that we probably can do better than > simply rubber-stamping any hacks a vendor with big pockets may bring up. That's a refreshing perspective. Refreshing, but confusing - given you promoted "standardizing

Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

FWIW - there are separable issues here: - whether an IP header (or parts thereof) should be changed in transit AFAICT, the answer has always been yes, but limited to the hopcount/ttl in the base header and hop-by-hop options in the options/extension headers. - whether an IP header length can

Re: [Int-area] [arch-d] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

On 2020-02-27 14:26, Phillip Hallam-Baker wrote: > On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert wrote: > >> Fernando, >> >> I think we need to be careful that IETF is labeled as a collection of >> inflexible architectural purists. We know that standards conformance >> is voluntary and we haven'

Re: [Int-area] SOCKS6 and UDP

> On Dec 12, 2019, at 6:47 AM, Vladimir Olteanu > wrote: > >> > All that >> > should be required is a functional TLS layer. (Session resumption might >> > not be supported by the library, it becomes complicated if you're using >> > an L4 load-balancer etc. etc.) >> >> True, if the TLS termina

Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

> On Nov 30, 2019, at 2:00 PM, Derek Fawcus > wrote: > > On Fri, Nov 29, 2019 at 09:01:35AM -0800, Joe Touch wrote: >> >> You’re not using 8 unused bytes. You are following RFC792 for the first >> three fields (first 4 bytes) and defining a new template for

Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

> On Nov 29, 2019, at 2:03 AM, Manoj Nayak wrote: > > Hello Joe, > > Sorry for the delayed response. > > >> - why does this doc assume the max ICMP is 576? > >> we?re still talking IPv4 here; it?s still 68 (that?s why only 64 bits > >> of the orig payload are guaranteed) > >> (yes,

Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

soft state information about each tunnel: > > - MTU of the tunnel (Section 5.1 > <https://tools.ietf.org/html/rfc2003#section-5.1>) > - TTL (path length) of the tunnel > - Reachability of the end of the tunnel > > > Regards > Manoj Nayak > > F

Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

> On Nov 20, 2019, at 8:14 PM, Manoj Nayak wrote: > > Hello Fred, > > Yes, it is possible that the largest fragment received is *much* smaller than > the PMTU. However, a survey of > popular operating systems reveals that the largest fragment does reflect the > PMTU. That’s great if that’s

Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

> On Nov 13, 2019, at 8:34 PM, Manoj Nayak wrote: > > Hello Joe, > > Please find my reply. > >>> - why does this doc assume the max ICMP is 576? >>> we?re still talking IPv4 here; it?s still 68 (that?s why only 64 bits >>> of the orig payload are guaranteed) >>> (yes, your note in

Re: [Int-area] Int-area Digest, Vol 170, Issue 14

never find the max the way you propose" > > > Regards > Manoj Nayak > >-Original Message- >From: Joe Touch >Sent: Wednesday, October 30, 2019 12:44 AM >To: Ron Bonica >Cc: int-area@ietf.org >Subject: Re: [Int-area] New Version Notification

Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt

FWIW, it could also be "Receiver PMTUD" (vs Packetization Layer, etc.). Again, though, the trouble is it doesn't overcome the issue with PMTUD of ICMP black-holing. It is easier to deploy for experimental purposes (runs only at the receiver rather than on all intermediate hops), but that's the on

Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt

On 2019-11-01 09:44, Fred Baker wrote: > On Nov 1, 2019, at 12:39 AM, Joe Touch wrote: On Oct > 31, 2019, at 5:07 PM, Erik Kline wrote: > It may be folly to try to modify IPv4 implementations at this point. I have > no objections if you wish to try pushing this big rock up

Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt

> On Oct 31, 2019, at 5:07 PM, Erik Kline wrote: > > It may be folly to try to modify IPv4 implementations at this point. I have > no objections if you wish to try pushing this big rock up hill, but I doubt > you will be successful. > > BTW, what *actually* prevents a middlebox from doing

Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

Hi, Ron, A few things come to mind. The first one, IMO, renders the rest somewhat less important. Joe - - this approach applies only to IPv4; not sure it’s worth trying to optimize for only that case (it requires on-path fragmentation permitted) - this approach relies on

Re: [Int-area] GUE: IANA Considerations question

It would also be useful to understand why you think more than one code point is needed for experiments (vs the RFC6994-style approach). Joe > On Oct 23, 2019, at 7:36 AM, Bob Hinden wrote: > > Greg, > >> On Oct 23, 2019, at 6:44 AM, Greg Mirsky > > wrote: >> >>

Re: [Int-area] New Version Notification for draft-herbert-ipv4-hbh-destopt-00.txt

> On Oct 1, 2019, at 1:45 AM, Frank Brockners (fbrockne) > wrote: > > Expanding from Bob's preference: IMHO it would make sense to explore what we > can solve with extension headers (HbyH and DO) - rather than argue the past > or judge from the past. Hardware is changing - and what used to b

Re: [Int-area] Existing use of IP protocol 114 (any 0-hop protocol)

Hi, Eric, > On Sep 23, 2019, at 1:40 AM, Eric Vyncke (evyncke) wrote: > > Now, it would nice to have a volunteer to write a document to finally > document those “Any bla” protocol number by putting common sense > restrictions/constraints on them (protocols 9/IGP, 61/host internal, 63/local >

Re: [Int-area] New Version Notification for draft-herbert-ipv4-hbh-destopt-00.txt

that the default data plane is functional turns out to be worse than > useless, as it has the potential to mislead the operator about where and what > the problem is. > > Thanks, --David > > From: Int-area mailto:int-area-boun...@ietf.org>> > On Behalf Of Joe Touch > S

Re: [Int-area] New Version Notification for draft-herbert-ipv4-hbh-destopt-00.txt

Hi, Tom, > On Sep 26, 2019, at 7:54 AM, Tom Herbert wrote: > > Joe, > > Your arguments seems to be more against use of Hop-by-Hop options in general. My concern is that you are trying to copy what appears to be a failed approach. I have no position on whether it *should* fail, but more rather

Re: [Int-area] New Version Notification for draft-herbert-ipv4-hbh-destopt-00.txt

Hi, Tom, I’ll resend my primary concern: > On Sep 25, 2019, at 8:46 AM, Tom Herbert wrote: > > On Tue, Sep 24, 2019 at 8:38 PM Joe Touch wrote: >> ... >> - that said, why is this supposed to help? can you give us examples of >> successful IPv6 *options* deploy

Re: [Int-area] New Version Notification for draft-herbert-ipv4-hbh-destopt-00.txt

Not that I think this is a good idea, but if it proceeds: - it’s worth noting in this doc that although IPv4 has its own option space, the extension header method is ALREADY how IPsec is defined as an IPv4 option, i.e., IPv4 protocol *always meant* next header anyway - HBH options MUST be copie

Re: [Int-area] [ih] Fwd: Existing use of IP protocol 114 (any 0-hop protocol)

> On Sep 21, 2019, at 2:20 PM, Brian E Carpenter > wrote: > > On 21-Sep-19 17:45, Joe Touch wrote: >> Hi, all, >> >> I wouldn’t care if this doc used 114 - as long as it is very clear that 114 >> is for *ANY* 0-hop protocol, which means ANYONE else can al

Re: [Int-area] [ih] Fwd: Existing use of IP protocol 114 (any 0-hop protocol)

<mailto:brian.e.carpen...@gmail.com>> wrote: > On 21-Sep-19 14:11, Joe Touch wrote: > > FWIW, there are many registries with such “dead” entries. > > 114 is a bit special. By definition, all our normal traffic monitoring > techniques will *never* see protocol 114 unless by

Re: [Int-area] [ih] Fwd: Existing use of IP protocol 114 (any 0-hop protocol)

FWIW, there are many registries with such “dead” entries. RFC6335 talks about the issue in trying to recover such entries. In general, it recommends that even if they are recovered, at best they would be marked as “RESERVED” until other values have been assigned and the space requires reuse of

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

> On Sep 13, 2019, at 5:05 AM, Fred Baker wrote: > > And the link layer could include capabilities such as described in RFC 1990… Wouldn’t this required: a) stateful associations between all link endpoints b) all links be 2-party only c) intermediate devices be happy to handle fragments that

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

> On Sep 13, 2019, at 4:59 AM, Ole Troan wrote: > >> Ron, it is just a drop in the bucket compared with the amount of discussion >> since >> "Fragmentation Considered Harmful (1987)". But, I think we now clearly see a >> case where fragmentation is *required*. > > Absolutely. As tunnels prod

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

> On Sep 12, 2019, at 6:57 AM, Templin (US), Fred L > wrote: > >>> IPv4 with a small PMTU also comes to mind, as discussed in Section 3.2.2 of >>> RFC 4213: >>> >>> In this case, the IPv6 layer has to "see" a link >>> layer with an MTU of 1280 bytes and the encapsulator has to use IPv4 >

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

First, IPv4’s minimum is 68, not 64. The header can be up to 60 octets and the smallest fragment is 8 bytes. Second, the problem with the logic that “bigger avoids fragmentation” is that the very specification of ANY minimum MTU, coupled with IP-in-IP tunnels (for their own sake, or as part of

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

-Original Message- >> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Fernando Gont >> Sent: Monday, September 09, 2019 1:47 PM >> To: Joe Touch ; Bob Hinden >> Cc: draft-ietf-intarea-frag-frag...@ietf.org; int-area@ietf.org; IESG >> ; Suresh Krishnan

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

> On Sep 8, 2019, at 8:50 PM, Brian E Carpenter > wrote: > > On 09-Sep-19 12:15, Joe Touch wrote: >> >> >>> On Sep 8, 2019, at 1:26 PM, Brian E Carpenter >> <mailto:brian.e.carpen...@gmail.com>> wrote: >>> >>>>> >&

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

> On Sep 8, 2019, at 1:26 PM, Brian E Carpenter > wrote: > >>> >>> Wouldn't that require the middle box to become an architectural element? >> >> Yes, but not just “an” (one): >> >> Touch, J: Middlebox Models Compatible with the Internet. USC/ISI >> (ISI-TR-711), 2016. (Type: Technical Rep

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

> On Sep 8, 2019, at 6:16 AM, Fred Baker wrote: > > > >> On Sep 5, 2019, at 5:31 PM, Tom Herbert wrote: >> >> I really wish the IAB would look at the issues of wide >> spread middlebox non-conformance > > Wouldn't that require the middle box to become an architectural element? Yes, but no

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

FWIW, in general: With all the concern not detecting when frag fails, I’d like to point out that it’s equally impossible to detect when it works, e.g., when it happens on tunnels that start more than one hop away or more than one layer of intermediate headers. E.g, PLPMTUD turns of frag *on th

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

> On Sep 7, 2019, at 2:09 AM, Ole Troan wrote: > >>> 1) It introduces something new and undescribed in paragraph 2. >>> "unless they also include mechanisms to detect that IP fragmentation >>> isn't working >>> reliably." >>> That seems like hand-waving to me. Suggest delet

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

> On Sep 6, 2019, at 9:03 AM, Ole Troan wrote: > > Joe, > > edited to focus on the two added "recommendation sentences". > > 1) It introduces something new and undescribed in paragraph 2. > "unless they also include mechanisms to detect that IP fragmentation > isn't working >

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

> On Sep 6, 2019, at 7:50 AM, Ole Troan wrote: > > Joe, > >> Comments below. >> >>> On Sep 5, 2019, at 11:33 PM, Ole Troan wrote: >>> >>> Bob, et al, >>> >>> I have two issues with this text. >>> >>> 1) It introduces something new and undescribed in paragraph 2. >>> "unless they also inc

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

Comments below. > On Sep 5, 2019, at 11:33 PM, Ole Troan wrote: > > Bob, et al, > > I have two issues with this text. > > 1) It introduces something new and undescribed in paragraph 2. > "unless they also include mechanisms to detect that IP fragmentation isn't > working > reliably." >

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

Although this is close, it misses the mark a little on the issue that the app may not actually have any control here - or know how or when to reduce its MTU. That might be a minor point to add, but is worth adding. This isn't just an app layer issue. Joe On 9/5/2019 4:45 PM, Ron Bonica wrote: > B

Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

On 9/5/2019 5:20 PM, Tom Herbert wrote: > That's exactly how fragmentation is productively used today, > particularly in those use cases of IPIP tunneling where fragmentation. > There was a lot of discussion about this on the list. Telling someone > who has been happily using fragmentation for year

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

> On Sep 4, 2019, at 10:34 AM, Ron Bonica wrote: > > If we follow the second path, we will need to figure out what to do with this > document. Options are: > > - Abandon it > - Progress it as it was approved by the IESG and ignoring all contrary > opinions > - Progress it as it was approved

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

fore, in order to robustly support > the minimum IPv6 MTU tunnels MUST employ fragmentation. > > Please put this section of text back in the document where it belongs. > > Thanks - Fred > > -Original Message- > From: Int-area [mailto:int-area-boun...@ietf.org] On

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

On 2019-09-04 11:05, Fred Baker wrote: > I did some of the edits, so I'll respond. Alissa issues a comment. We also > got several other comments over the summer. This update responds to a set of > comments. I'm on vacation and mostly out of contact, so my co-authors will > need to proceed as ap

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-16.txt

Bob, On 2019-09-03 14:08, Bob Hinden wrote: > Joe, > >> On Aug 30, 2019, at 4:36 PM, Joe Touch wrote: >> >> Hi, all, >> >> I disagree with the changes indicated in this version. >> >> The new text is both incorrect does not IMO reflect WG co

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

On 2019-09-04 08:29, Bob Hinden wrote: > This text has been through IETF last call and IESG review, and as far as I > can tell is factually correct. Unless we want to repeat that, better to not > remove it in my view. Repeating it up front was through WG and IETF last call. If IESG r

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

On 2019-09-04 07:23, Templin (US), Fred L wrote: > Bob, > ... > Paragraph #1 beginning "This document acknowledges" looks good, but then > why include paragraphs #2 and #3 since 'intarea-tunnels' is the place to > discuss > IP-in-IP encapsulation. So, why not shorten Section 5.3 and have it as s

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

art of addressing the problem should also be to fix the problem! That >>> is implementations should be fixed to deal with fragmentation. IMO, >>> this should be another high level recommendation that is mentioned in >>> the introduction. >> >> I am serving

Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

Hi, all, So let me see if I understand: Alissa issues a comment. We discuss this on the list and come to a rare consensus on a way forward. The new draft is issued that: a) ignores the list consensus b) removes a paragraph not under the DISCUSS (1.1) c) now refers to vague “other documents” wi

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-16.txt

Hi, all, I disagree with the changes indicated in this version. The new text is both incorrect does not IMO reflect WG consensus. It is simply false that "it WILL break" or "new protocols can't possibly know whether fragmentation works" - you even cite studies where this works the majority of

Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

> On Aug 15, 2019, at 7:26 AM, Ron Bonica wrote: > > Joe, > > All things are fragile. That's one of life's realities. > > But some things are more fragile than others. Sure, but what is the measure of “more”, esp. vs how many other features are fragile and break *all* communication? Unles

Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

Well, there’s the tautology that “it worked when it worked”. Given that’s basically the rule that defines *everything* in the Internet, it’s baffling we need to say it again here, but if we did, we could simply state: “The Internet is a best-effort system and lacks a formal validation or confor

Re: [Int-area] Warren Kumari's Yes on draft-ietf-intarea-frag-fragile-15: (with COMMENT)

Warren, FYI - #2 - IP-in-IP is the most typical case where a lack of fragmentation support causes problems. This isn’t a rare case; it’s the basis of IPsec tunnels and part of the reason why it’s impractical to simply deprecate this capability. #3 - while it might be worth noting even more de

Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

> On Aug 7, 2019, at 7:01 AM, Fernando Gont wrote: > > On 7/8/19 16:30, Joe Touch wrote: >> Things that don’t work aren’t always either deprecated or security attacks. >> >> And if we treat them as such, the remainder won’t be useful to anyone for >> an

Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

Things that don’t work aren’t always either deprecated or security attacks. And if we treat them as such, the remainder won’t be useful to anyone for anything. Joe On Aug 7, 2019, at 6:09 AM, Fernando Gont wrote: >> On 7/8/19 04:09, Joe Touch wrote: >> Yeah, but that’s the rub.

Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

Yeah, but that’s the rub. If we accept the status-quo of a failure to deploy devices that allow a valid protocol capability this way, we’ve basically deprecated it. That’s the bad idea that we’ve tried hard to avoid, IMO. Joe > On Aug 6, 2019, at 6:06 PM, Joel M. Halpern wrote: > > Brian, I

Re: [Int-area] [tsvwg] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019

ome to that defined by the "SHOULD" statements >throughout this section. "SHOULD" is only used to allow similar >perhaps more efficient approaches that result in approximately the >same outcome. > > > > > Bob > > On 16/05/2019

Re: [Int-area] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019

Cross-posting to let both communities know: - it would be useful for these documents to address how fragmentation and reassembly affects these signals (esp. if reassembling fragments with different ECN values) - it would be useful for these documents to consider draft-ietf-intarea-tunnel

Re: [Int-area] Questions about INT Area Tunnels draft: aft-ietf-intarea-tunnels-09

Hi, Gorry, Again, thanks for the detailed comments. We welcome them! Responses below... > On Apr 16, 2019, at 4:28 AM, Gorry Fairhurst wrote: > > > I have read draft-ietf-intarea-tunnels-09, because it is cited from another > document that I am reviewing. I have a number of technical questio

Re: [Int-area] Comments on INT Area Tunnels draft: aft-ietf-intarea-tunnels-09

Hi, Gorry, Thank you for the deep feedback - I’ve been waiting for this sort of input for quite a long time (from the community as a whole)... > On Apr 16, 2019, at 4:28 AM, gorry Fairhurst wrote: > > > I have read draft-ietf-intarea-tunnels-09, because it is cited from another > document th

Re: [Int-area] New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt

> On Mar 8, 2019, at 10:01 AM, Tom Herbert wrote: > > On Fri, Mar 8, 2019 at 9:42 AM Joe Touch wrote: >> >> >> On 3/8/2019 9:33 AM, Tom Herbert wrote: >>> UDP fragmentation would only with UDP, it doesn't help any other >>> transport proto

Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt

On 3/8/2019 9:33 AM, Tom Herbert wrote: > UDP fragmentation would only with UDP, it doesn't help any other > transport protovcol. Stream transports already do this for the entire stream. The only other exception might be DCCP - I'd have to check that. > Also, I don't understand how the fragme

Re: [Int-area] New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt

On 3/8/2019 7:56 AM, Tom Herbert wrote: > On Thu, Mar 7, 2019 at 11:57 PM Joe Touch wrote: >> >> On 3/7/2019 9:03 AM, Tom Herbert wrote: >>> 1) Allow IPv4 to carry IPv6 extension header numbers in the protocol >>> field, and process as IPv4 extension headers. &

Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt

On 3/8/2019 7:37 AM, Tom Herbert wrote: >> Isn't the general consensus to move away from fragmentation as much as >> possible? >> > I don't believe so. There are still a lot of valid use cases for > fragmentation. draft-ietf-intarea-frag-fragile-09 talks about the > current state fo fragmentation.

Re: [Int-area] New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt

On 3/7/2019 9:03 AM, Tom Herbert wrote: > 1) Allow IPv4 to carry IPv6 extension header numbers in the protocol > field, and process as IPv4 extension headers. I heard someone on another list argue strongly for fixed headers of the sort IPv4 already uses. ;-) > 2) Encapsulate extension headers a

Re: [Int-area] New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt

Tom, > On Mar 7, 2019, at 7:53 AM, Tom Herbert wrote: > Yes, some intermediate nodes will arbitrarily drop packets. Some will > only allow certain UDP ports, some will drop all IPv6, some will drop > every transport protocol but TCP, some will drop packets with > extension headers, some will

Re: [Int-area] New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt

> On Mar 6, 2019, at 2:38 PM, Tom Herbert wrote: > > On Wed, Mar 6, 2019 at 10:59 AM Joe Touch <mailto:to...@strayalpha.com>> wrote: >> >> >> >> >> >> On 2019-03-06 09:12, Tom Herbert wrote: >> >> On Wed, Mar 6, 2019 at

Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt

On 2019-03-06 09:12, Tom Herbert wrote: > On Wed, Mar 6, 2019 at 9:03 AM Joe Touch wrote: > >> ... >> >> And yes, we can build an Internet on the Internet - again, as I've noted >> repeatedly throughout the IETF. Or we can use UDP fragmentation - which &g

Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt

On 3/6/2019 8:22 AM, Tom Herbert wrote: > On Tue, Mar 5, 2019 at 10:08 PM Joe Touch wrote: >> Isn't the biggest problem with IP fragmentation the inability to NAT >> because the transport headers are in the first fragment only (which may >> go via another path)? >&g

Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-udpencap-eh-00.txt

Isn't the biggest problem with IP fragmentation the inability to NAT because the transport headers are in the first fragment only (which may go via another path)? I.e., 6864 already relaxes the ID field to allow reuse as long as it's not within expected reordering, overcoming the speed limit.  Jo

Re: [Int-area] Comment on draft-ietf-intarea-frag-fragile-02

First, this MTU discussion is quite vague. There are link MTUs, path MTUs, and tunnel MTUs and they’re different. Nobody building a network knows anything about the encapsulation overhead being used by tunnels - many of which are never even detected by operators. They might know about a few le

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt

gt; >>> -Original Message- >>> From: Tom Herbert [mailto:t...@herbertland.com] >>> Sent: Thursday, January 31, 2019 5:17 PM >>> To: Templin (US), Fred L >>> Cc: Joe Touch ; Ron Bonica ; >>> int-area >>> Subject: Re: [Int-area] I-D Ac

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt

> On Feb 1, 2019, at 7:39 AM, Templin (US), Fred L > wrote: > >> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_frre/configuration/xe-3s/frre-xe-3s-book/virt-frag-reassembly.html >> >>

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt

Virtual reassembly means “forwards *as if* reassembled”, without actually reassembling. It’s actually not all that much different from the way NATs or unidirectional firewalls work for TCP. On Feb 1, 2019, at 12:42 AM, Ole Troan wrote: > > if first fragment in chain > found = lookup 4 tuple

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt

Reassembly is described in detail in RFC 791. Joe > On Jan 31, 2019, at 4:39 PM, Tom Herbert wrote: > >> On Thu, Jan 31, 2019 at 3:10 PM Joe Touch wrote: >> >> >> >> >> >> On 2019-01-31 13:56, Tom Herbert wrote: >> >> On T

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt

On 2019-01-31 13:56, Tom Herbert wrote: > On Thu, Jan 31, 2019 at 7:59 AM Joe Touch wrote: > >> The problem with dropping the entire paragraph is the section title - >> talking about stateless firewalls begs the question of stateful ones. This >> is reinforced late

Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt

The problem with dropping the entire paragraph is the section title - talking about stateless firewalls begs the question of stateful ones. This is reinforced later in the recommendations. The sentences you remove were the only thing that tied the two together, which IMO is important. Also note

Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

> On Jan 18, 2019, at 7:39 AM, Tom Herbert wrote: > >> On Thu, Jan 17, 2019 at 9:24 PM Joe Touch wrote: >> >> When I call them (multihomed) hosts, I never would assume that the >> experiment you propose would work. However, if I limit the paths to go >

Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

or explain it. Joe > On Jan 17, 2019, at 3:46 PM, Tom Herbert wrote: > >> On Thu, Jan 17, 2019 at 3:17 PM Joe Touch wrote: >> >> >> >> On Jan 17, 2019, at 1:09 PM, Tom Herbert wrote: >> >> Joe, >> >> When they attempt to do hos

Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

> On Jan 17, 2019, at 3:17 PM, Joe Touch wrote: > ,,, > >> But, in that case we really need the specification of the protocol to >> have a meaning discussion about it. > > RFC 791 and 1122 provide everything that is needed. > > It’s not new, it’s just not

Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

> On Jan 17, 2019, at 1:09 PM, Tom Herbert wrote: > > Joe, > > When they attempt to do host processing on packets that don't belong > to them they're not hosts. They are every host for whose packets they process. > And when they do this, they impose a new > requirement that hosts do not have

Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

Hi, Tom, On 2019-01-17 08:58, Tom Herbert wrote: > On Thu, Jan 17, 2019 at 8:24 AM Joe Touch wrote: > >> ... >> Hint - if a packet arrives on your interface with your IP address, you ARE a >> host. >> >> Joe, >> >> Conversley, if a packet arr

Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

Hi, Tom, On 2019-01-17 07:27, Tom Herbert wrote: > On Thu, Jan 17, 2019 at 7:06 AM Joe Touch wrote: > Hi Tom, > > On Jan 17, 2019, at 6:55 AM, Tom Herbert wrote: > ... > > As I mentioned, in-network reassembly has not been specified, only > reassembly at end destin

Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

Hi Tom, > On Jan 17, 2019, at 6:55 AM, Tom Herbert wrote: > >> On Wed, Jan 16, 2019 at 10:20 PM Joe Touch wrote: >> >> Tom, >> >> On 1/14/2019 2:04 PM, Tom Herbert wrote: >> >> Hello. I have a couple of comments: >> >>> Fr

Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom Herbert)

FWIW... On 1/16/2019 11:26 AM, Tom Herbert wrote: > ...A stateless firewall could just drop the first fragment that > contains the transport layer header and allow non first fragments to > past. This achieves the filtering goal to prevent delivery of the > reassmbled packet. That works only if th

Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

Tom, On 1/14/2019 2:04 PM, Tom Herbert wrote: > Hello. I have a couple of comments: > > >From the draft: > "Middle boxes SHOULD process IP fragments in a manner that is > compliant with RFC 791 and RFC 8200. In many cases, middle boxes must > maintain state in order to achieve this goal." > > Thi

Re: [Int-area] draft-ietf-intarea-frag-fragile-03

> On Nov 30, 2018, at 2:57 PM, Tom Herbert wrote: > > ...student writing a quick UDP app in their dorm room to have to consider > all the pitfalls of fragmentation and whether they need to increase > their complexity by an order of magnitude to implement fragmentation > in their application. Th

Re: [Int-area] draft-ietf-intarea-frag-fragile-03

> On Nov 30, 2018, at 9:46 AM, Ole Troan wrote: > > > >> On 30 Nov 2018, at 18:33, Joe Touch wrote: >> >> >> >>> On Nov 30, 2018, at 9:22 AM, Ole Troan wrote: >>> >>> >>> >>>> On 30 Nov 2018, at 16:4

Re: [Int-area] draft-ietf-intarea-frag-fragile-03

> On Nov 30, 2018, at 9:22 AM, Ole Troan wrote: > > > >> On 30 Nov 2018, at 16:49, Joe Touch wrote: >> >> 1) the lower down the fragmentation occurs, the less overhead is needed >> (i.e., when performance is an issue, it’s even more important to fragme

Re: [Int-area] draft-ietf-intarea-frag-fragile-03

If what you say were true, then we should all run everything over UDP and skip TCP. There are two reasons to the contrary: 1) the lower down the fragmentation occurs, the less overhead is needed (i.e., when performance is an issue, it’s even more important to fragment as low as possible) 2) it

Re: [Int-area] draft-ietf-intarea-frag-fragile-03

I would hope it would be evident from context, but sure. Joe > On Nov 29, 2018, at 8:37 AM, Stewart Bryant wrote: > > > Either way it is useful to give the reviewer a heads up as to nits giving > errors and this being OK. > > S > >> On 29/11/2018 14:42, Joe T

Re: [Int-area] draft-ietf-intarea-frag-fragile-03

was obsoleted by RFC 3530 in 2003 > - RFC 3530 was obsoleted by RFC 7530 in 2015 > - We are citing NFSv2 in a draft that will be published in 2019 > o I will be 61 years old by then. > > >

Re: [Int-area] draft-ietf-intarea-frag-fragile-03

e reviewers to stop > then all sending in feedback about the nits failure. > > Stewart > > >> On 27/11/2018 20:42, Joe Touch wrote: >> FWIW: >> >> >> >> >>> On 2018-11-27 12:22, Ron Bonica wrote: >>> >>> Fred, >&

  1   2   3   4   5   6   7   8   9   >