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

[Joe Touch]

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. Check the RFC if you don’t believe me. 
> 
> Dino
> 
>> On Feb 28, 2022, at 9:29 PM, to...@strayalpha.com wrote:
>> 
>> 
> On Feb 28, 2022, at 8:00 PM, Dino Farinacci  wrote:
> 
> There is a base case to the recursion, i.e., where logical information 
> meets fermions and bosons (literally). But that tells you only that base 
> layer; it tells you nothing about the meaning of the headers you see 
> inside, e.g., in OSI, they would be 1,2,3,4,5,6,7, but in an IP tunnel, 
> they could be 1,2,3,3,4,5,6,7, with GRE they could be 1,2,3,2,3,4,5,6,7, 
> etc.
>>> 
>>> An IP tunnel with protocol number 4 is indeed 1,2,3,3,4,5,6,7, but LISP 
>>> (UDP port 4341) UDP tunnels are 1,2,3,4,3,4,5,6,7 and GRE is 
>>> 1,2,3,3,4,5,6,7 because it runs directly over IP with protocol number 47.
>>> 
>>> Dino
>> 
>> If GRE runs over IP, then it would be the same as IP-over-UDP tunnels:
>> 
>> 1,2,3(IP), 4(GRE, since it is a protocol number of IP), 3(IP in GRE), 5,6,7, 
>> i.e.: 1,2,3,4,3,4,5,6,7
>> 
>> It’s all actually relative, though - to the left IP, GRE is layer 4. To the 
>> right IP, GRE is layer 2.
>> 
>> Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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?

If so, ARP is learning - just the simplest kind.  Without name structure that 
maps to network topology, there’s nothing else to learn. 

Or did you mean something else?

Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

Hi Fred,

It’s not possible to claim any one layer solves this. MTU is inherently a 
multilayer issue, and that’s perspective that’s missing, IMO. 

Note that I don’t think this can be solved the way I’m asking in the current 
layering, even with shim layers. 

But that was the question asked. 

Joe

> On Dec 3, 2021, at 2:07 PM, Templin (US), Fred L  
> wrote:
> 
> 
> Joe, AAL5 adapted to heterogeneous Internetworks does the job properly as
> part of a multi-layered segmentation and reassembly solution. See also:
>  
> https://datatracker.ietf.org/doc/draft-templin-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 from the 
> Internet?
>  
>  
> —
> Joe Touch, temporal epistemologist
> www.strayalpha.com
> 
> 
> On Dec 3, 2021, at 10:06 AM, Templin (US), Fred L  
> wrote:
>  
> Joe, I was going to let this slide but this is the most words you have spoken 
> to
> me in a single message in many years.
>  
> Sorry - my day job keeps me quite busy….
> 
> 
> What AERO/OMNI enable is lossless and
> adaptive packet sizing to determine the best-performing size for a given flow
> *even if that size exceeds the path MTU*. I think this honors the past works 
> that
> you seem to hold as sacred – both from yourself and from others.
>  
> What more do you want?
>  
> As a mechanism, nothing. But that mechanism has to be widely deployed and 
> arguably available at multiple layers. I wish we had an approach that didn’t 
> have the same kind of notion of MTU as IP, but rather more like Ethernet, as 
> I noted before - which would obviate the need for frag/reassembly except at 
> the uppermost app layer.
>  
> Joe
> 
> 
>  
> Fred
>  
> From: to...@strayalpha.com [mailto:to...@strayalpha.com] 
> Sent: Friday, December 03, 2021 7:33 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 from the 
> Internet?
>  
> Fred,
>  
> Having a mechanism that *can* be used at any layer to address fragmentation 
> isn’t the same as solving the MTU issue.
>  
> Issues that complicate this are:
> - not all layers employ that mechanism or any other
> - too many ‘layers’ peek into payload contents for message dispatch (of one 
> sort or another)
>- which means that if the fragmentation doesn’t copy enough of 
> the payload, that dispatch breaks
>(lack of transport port numbers for IP frags, lack of HTTP 
> headers for web message frags, etc.)
>  
> So whether it’s because solution are incomplete or not widely adopted, or 
> both, it’s not solved.
>  
> Joe
>  
> —
> Joe Touch, temporal epistemologist
> www.strayalpha.com
> 
> 
> 
> On Dec 3, 2021, at 6:37 AM, Templin (US), Fred L  
> wrote:
>  
> Joe, yes MTU was hard – very hard – but it is now solved.
>  
> From: to...@strayalpha.com [mailto:to...@strayalpha.com] 
> Sent: Thursday, December 02, 2021 5:21 PM
> 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 from the 
> Internet?
>  
> All waists, like all layers except those that touch the physical (e.g., MAC 
> protocols) are relative.
>  
> It’s a lot like the ‘end’ in E2E. It was thought to imply “that which can be 
> kicked”, but it’s really “that which *I* can kick”.
>  
> Once you accept this relativity, everything else just works - including the 
> reason why OSI got it completely wrong - layers are not uniquely defined by 
> functions/capabilities. That’s the reason why MTU is so hard - everyone wants 
> it to be ‘fixed’ at a single layer, but it can’t be.
>  
> —
> Joe Touch, temporal epistemologist
> www.strayalpha.com
> 
> 
> 
> 
> On Dec 2, 2021, at 2:22 PM, Templin (US), Fred L  
> wrote:
>  
> Depends on what you consider to be the “waist”; the adaptation layer is below 
> the
> IP “waist” and (again) is missing from your diagram.
>  
> From: Dino Farinacci [mailto:farina...@gmail.com] 
> Sent: Thursday, December 02, 2021 2:18 PM
> To: Templin (US), Fred L 
> Cc: Stewart Bryant ; int-area@ietf.org; Dirk 
> Trossen 
> Subject: Re: [Int-area] Side meeting follow-up: What exact features do we 
> want from the Internet?
>  
> 
>  
> You missed the point maybe. Common functions should be performed at the waist 
> so applications don’t have to duplicate functio

Re: [Int-area] Tunnels and Fragmentation

[Joe Touch]

> 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
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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
>> 
>> 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 change in transit
>> 
>> I see no reason why it can't become smaller, but if it can become larger 
>> then PMTUD and PLPMTUD don't work.
> 
> Besides AH (which obviously breaks), hosts typically try to validate that the 
> error messages they receive correspond to something they actually sent.
> 
> EH removal breaks that.___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 header it wants but needs to do
fragmentation (and potentially PLPMTUD over the tunnel with the egress).


Egress can strip the outer header but not make the inner one bigger,
IMO. 

Is something else being proposed? 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

Hi, Robert, 

It doesn't matter on what IP header this occurs. 

It does matter whether it happens at the IP source (origin host, tunnel
ingress, etc.) or on the path of that header. 

The former is allowed exactly because it is where source fragmentation
can occur (in IPv6, and preferably the only kind of fragmentation used
in IPv4). 

Joe

On 2020-02-27 15:04, Robert Raszuk wrote:

> Joe, all, 
> 
> Just to clarify something Fernando purposely missed in his call for action: 
> 
> All operations on the packets discussed in SPRING WG are happening NOT on the 
> original (end to end) packet header. They are all defined to happen within 
> new imposed outer encapsulated header (IPv6 in IPv6 to be precise).  
> 
> So original packet just get's tunneled between various points of the network. 
> Last time I checked that operation is allowed by 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 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 change in transit 
>> 
>> I see no reason why it can't become smaller, but if it can become larger 
>> then PMTUD and PLPMTUD don't work. 
>> 
>> So the question isn't just what is wanted, it's what is feasible. 
>> 
>> Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 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 change in transit
>> 
>> I see no reason why it can't become smaller, but if it can become larger 
>> then PMTUD and PLPMTUD don't work.
>> 
>> So the question isn't just what is wanted, it's what is feasible.
> Joe,
> 
> Per the problem about making packets larger in the network, I'd point
> out that this is already common due to in-network tunneling. In any
> case, it's really the only interesting case here (as opposed to making
> packets smaller).

Tunnels don't make packets bigger. They make a bigger packet at the
tunnel level. That then becomes the tunnel's problem to deal with (see
draft-intarea-tunnels). 

Making the IP packet bigger itself creates a problem that cannot be
recovered that way. 

I.e., same problem but very different consequences. 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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" vendor
deviations (many arguably bugs) from TCP in TCPM. 

So I'm confused - what do you think drives our standards now? Design or
implementations (including bugs)? 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 change in transit 

I see no reason why it can't become smaller, but if it can become larger
then PMTUD and PLPMTUD don't work. 

So the question isn't just what is wanted, it's what is feasible. 

Joe

On 2020-02-27 14:07, 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't seen the last time that someone, possibly
> even a major vendor, will circumvent the system for their own
> purposes. IMO extension header insertion is a great example of that.
> On one hand we have people quoting IPv6 saying that it isn't allowed
> per RFC8200-- period! And on other side there are proponents that see
> a real need for it and believe they have clear use case-- at one
> presentation in IETF a proponent bluntly stated that regardless of any
> discussion in IETF they're going to do it! IMO, what we haven't seen,
> was a real attempt to resolve and work out the engineering issues.
> That's not for lack of trying-- for instance I proposed a direction to
> try for an engineering compromise in draft-herbert-6man-eh-attrib-00,
> but saw little discussion on that.
> 
> Tom
> 
> On Thu, Feb 27, 2020 at 1:43 PM Fernando Gont  wrote: 
> 
>> Folks,
>> 
>> If you haven't been following recent developments in the Spring WG, you
>> may be surprised about some of the work that is being pursued (or was
>> being pursued)-
>> 
>> Such work has included proposing that some IPv6 routers insert and
>> remove routing headers en-route to the final destination.
>> 
>> After many very heated and lengthy debates, some of this work was
>> dropped, but other remains (e.g. routers removing IPv6 EHs from packets
>> en-route to their final destination, part of what they call "PSP"). For
>> the most part, the proponents have argued that "we have implemented it,
>> and the industry wants it" -- as if we just have to rubberstamp what
>> they have done.
>> 
>> On the technical side, the proponents have argued that:
>> 
>> If a packet employs source routing (and hence its Destination
>> Address is modified en-route to direct the packet through each
>> of these "waypoints"), then any of such "waypoint" routers are
>> free to add or remove IPv6 extension headers at will. (No, not
>> encap/decap, but rather add/remove EHs from the IPv6 header
>> chain).
>> 
>> That seems to me like a very major deviation from what's supposed to be
>> our current "architecture", where IPv6 is an end to end protocol.
>> Besides, it should be obvious that removal/insertion of EHs en-route
>> error reporting (since host typically check that the ICMP errors they
>> receive correspond to something that they actually sent).
>> 
>> A number of us have raised this a number of times, and at least some of
>> us feel that our concerns are being ignored.
>> 
>> It would seem to me that these documents and decisions have a concrete
>> impact on our architecture, and that they are being pursued without any
>> proper oversight. There is also a widespread feeling that having one or
>> a few big vendors pushing these ideas might be playing a role here.
>> 
>> (See, for instance:
>> 
>> * https://mailarchive.ietf.org/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXvPcpj4/
>> 
>> * https://mailarchive.ietf.org/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc/
>> )
>> 
>> What I would expect is that all thes major changes to our existing
>> architecture and protocols would only done by formally updating existing
>> standards *if* deemed appropriate, as opposed to just trying to sneak
>> changes "when nobody is watching", or by having very curious
>> interpretations of our protocols and standards.
>> 
>> I've raised the topic to our AD (Suresh), to the IAB, and on the arch-d
>> list before, but so far haven't been lucky or seen anything meaningful
>> happen in this area.
>> 
>> I have also submitted an errata to make RFC8200 even more clear on the
>> topic, but it remains unprocessed.
>> 
>> So my questions are:
>> 
>> * On the technical area:
>> 
>> + Is IPv6 an End To End protocol?  Or is the IETF's stance that
>> routers are free to mangle with the packet structure as they please?
>> 
>> + Was IPv6 designed that way? And if it wasn't, when/how was the
>> architecture changed?
>> 
>> * On the procedural area:
>> 
>> + Where/how should IETF WGs seek for architecture-related advice?
>> 
>> + What do do in situations like the above?  Wait and see how things
>> evolve, and upon any formal decisions, just submit formal Appeals
>> if deemed necessary?  (and after way too much energy consumed from
>> everyone)
>> 
>> I would have expected that as soon as these issues were 

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

[Joe Touch]

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't seen the last time that someone, possibly
>> even a major vendor, will circumvent the system for their own
>> purposes.
> 
> IP end to end does not mean the IP address is constant end to end. It never 
> has meant that and never will.

Actually, that's the only thing it ever meant and always will. When
addresses change, *by definition*, the*ends* change (and yes, that's
what NATs do - they create end-to-end CONTENT transfer over separate
end-to-end Internets). 

> ..
> We discovered that there were good reasons for NATing IPv4 besides address 
> multiplexing. The topology of my network is none of your business.

Agreed; there's nothing that forces you to use IP addresses in a way
that exposes your topology (you're free to build a net using host
routing). That has nothing to do with NAT. 

I have not found a rationale for NATs that doesn't start and end with a
business model where servers are charged business rates and clients are
charged customer rates. Everything else about NATs either isn't a NAT
property (hiding topology) or can be achieved by a stateful firewall
(that predates NATs by a decade, e.g. that lets outgoing connections go
through but not incoming). 

> More generally, Internet standards only apply to the Inter-net, the network 
> of networks. What happens inside the networks at either end is for the owners 
> of those networks to decide. If we go back to the original Internet design, 
> they didn't even need to run IP. IP end to end come later.

That's true, but then their "end" on the public Internet would be the
firewall or NAT box at their edge. 

> So let us stop being dogmatic about things that don't actually matter. The 
> only job of the network layer is to get packets from one end to another. The 
> only job of the transport layer is to provide reliable streams. An 
> application protocol that depends on the IP address remaining constant end to 
> end is a bad protocol and should be rejected.

That's a very OSI view of protocols - about as out-dated and about as
useful., IMO. Every layer of the stack might be involved in any
function; anything that claims a single layer owns a single job hasn't
existed since at least IP over IP. 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] SOCKS6 and UDP

[Joe Touch]

> 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 termination is implemented separately from the SOCKS server 
>> then this could be hard to achieve.  Port 1080 is reserved for SOCKS on both 
>> TCP and UDP, so maybe this requirement could apply only when using TLS and 
>> DTLS on the same host and port.
>> 
> It could be that TLS and DTLS are terminated by separate processes, or even 
> separate machines, ..
> 
Same IP address means it would need to act as if it were the same machine. 
Coordinating shared use of an IP address between two separate hosts is the 
implementers problem, not the protocol designers.

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 the next 4. 
> 
> I'd suggest they seem to be starting from RFC 4884 (although they do not 
> reference it),
> and then seeing what else they can do.

That may be where they’re getting the “as much of the datagram as possible” 
part in some cases, but not the 8 unused bytes.

But if so, they need to start with a citation.

Either way, we still end up where we started - we do PLPMTUD because ICMPs are 
too often blocked. Not just from routers.

Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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, your note in the end of sec 1 is relevant, but given v4-in-v4 
> >> tunneling, it?s possible that
> >> paths might be smaller than the 576 assumption)
>  
> >> We use an unused field in first 8 bytes of ICMP error/reply message.
>  
> >> Please explain. Most ICMP messages have 4 bytes of unused field, but not 
> >> all (one has only 3).
>  
>  
>   As per RFC 1191,  Destination Unreachable Message has 8 bytes unused 
> field.

DU has only 4 bytes unused, per RFC792.

Destination Unreachable Message

0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type  | Code  |  Checksum |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | unused|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Internet Header + 64 bits of Original Data Datagram  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RFC1191 uses half that space:

   ...To support the Path MTU Discovery
   technique specified in this memo, the router MUST include the MTU of
   that next-hop network in the low-order 16 bits of the ICMP header
   field that is labelled "unused" in the ICMP specification [7 
].  The
   high-order 16 bits remain unused, and MUST be set to zero.

>  
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |   Type = 3|   Code = 4|   Checksum
>  |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |   unused = 0  | Next-Hop MTU  
>   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |  Internet Header + 64 bits of Original Datagram Data|
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The diagram above  is from 1191 - there are 2 bytes unused.

>   Most of ICMP reply/error message need type, code and checksum in first four 
> bytes.
>   So our new ICMP message for this draft has the above three fields in first 
> four bytes.
>   We have used 1 byte for length and two bytes for Largest fragment. Our ICMP
>   Package looks as follows:
>  
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Type  | Code  |  Checksum |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Unused|Length |   Largest Fragment|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|  Original Datagram   
>  |
>|  
> |
>|   // 
>|
>|  
>  |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 the next 4. 

>   If the packet mentioned in RFC 1191 does not have any issue with tunnel
>   then

It does because it doesn’t include the entire original datagram….

> how tunnel can create problem for our packet.
> 
> >> Sending the largest response possible given an untunneled MTU size is an 
> >> invitation
> >> to black-hole the response itself if (when) an IPv4-in-IPv4 tunnel is 
> >> encountered.
> >> In most situations, ICMP responses are received from small initial 
> >> messages that don’t
> >> stress that limit. The use in this doc is the opposite - it relies on 
> >> ongoing use of ICMP
> >> for max-sized packets and returns max-sized payloads. This isn’t helpful. 
> >> It would be more
> >> useful to try to limit the size to the minimum expected to be useful and 
> >> account for
> >> these other encapsulations.
>  
> We have mentioned that Original Datagram will be there in the third row of 
> our ICMP packet.
> However Internet Header + 64 bits of Original Datagram Data is good enough 
> 

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

[Joe Touch]

You haven’t answered any of the questions I asked, including the one about 
tunnels.

The point about tunnels is that the numbers you’re assuming don’t account for 
the space needed for tunneling.

The portion of RFC2003 below acts like a router; it isn’t relevant to your 
mechanism. Sec 5.2 of draft-ietf-intarea-tunnels also points out several errors 
in that RFC, including those in how that RFC refers to and calculates MTUs.

Joe

> On Nov 23, 2019, at 6:23 AM, Manoj Nayak  wrote:
> 
> Hello Joe,
>  
> Section 5 of the below RFC talks about the way to relay MTU size to sender if 
> ipv4-to-ipv4 tunnel is
> there in the path from sender to destination.
>  
> There are two cases here.
>  
> Destination is outside tunnel.
> Destination is tunnel end point.
>  
> When destination is tunnel end point then MTU size is returned to sender 
> using soft state maintained
> at tunnel entry point.
>  
> https://tools.ietf.org/html/rfc2003 <https://tools.ietf.org/html/rfc2003>
>  
>  <>
> 5 <https://tools.ietf.org/html/rfc2003#section-5>. Tunnel Management
>  
>  
>Unfortunately, ICMP only requires IP routers to return 8 octets (64
>bits) of the datagram beyond the IP header.  This is not enough to
>include a copy of the encapsulated (inner) IP header, so it is not
>always possible for the encapsulator to relay the ICMP message from
>the interior of a tunnel back to the original sender.  However, by
>carefully maintaining "soft state" about tunnels into which it sends,
>the encapsulator can return accurate ICMP messages to the original
>sender in most cases.  The encapsulator SHOULD maintain at least the
>following 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
>  
> From: Joe Touch mailto:to...@strayalpha.com>>
> Date: Friday, 15 November 2019 at 8:20 PM
> To: Manoj Nayak mailto:manojna...@juniper.net>>
> Cc: "int-area@ietf.org <mailto:int-area@ietf.org>"  <mailto:int-area@ietf.org>>
> Subject: Re: [Int-area] New Version Notification for 
> draft-bonica-intarea-lossless-pmtud-00.txt
>  
>  
> 
> 
>> On Nov 13, 2019, at 8:34 PM, Manoj Nayak > <mailto:manojna...@juniper.net>> 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 the end of sec 1 is relevant, but given v4-in-v4 
>>>> tunneling, it?s possible that 
>>>> paths might be smaller than the 576 assumption)
>> 
>> We use an unused field in first 8 bytes of ICMP error/reply message. 
>  
> Please explain. Most ICMP messages have 4 bytes of unused field, but not all 
> (one has only 3).
> 
> 
>> How the idea would be
>> affected if minimum packet size is 68 bytes or 576 bytes. As per my 
>> understanding,
>> existing ICMP error/reply message works in v4-in-v4 tunnelling, so it would 
>> continue to 
>> work with the idea proposed in our draft. we won’t let the ICMP message 
>> exceed a reasonable size. 
>> in our implementation, that will be 576.
>  
> Sending the largest response possible given an untunneled MTU size is an 
> invitation to black-hole the response itself if (when) an IPv4-in-IPv4 tunnel 
> is encountered.
>  
> In most situations, ICMP responses are received from small initial messages 
> that don’t stress that limit. The use in this doc is the opposite - it relies 
> on ongoing use of ICMP for max-sized packets and returns max-sized payloads. 
> This isn’t helpful. It would be more useful to try to limit the size to the 
> minimum expected to be useful and account for these other encapsulations.
> 
> 
>> 
>> 
>>>> - why would this approach find the largest fragment through a system?
>>>>  rfc1812 talks about various strategies, one of which is ?equal 
>>>> sized?, which might never find 
>>>> the max the way you propose
>> 
>> 
>> As per section 4.2.2.7 from rfc 1812,
>> 
>> “There are several fragmentation techniques in common use in the
>> Internet.  One involves splitting the IP datagram into IP
>> fragments with the first being MTU sized, and the others being
>> approximately the same size, smaller than the MTU. “
>> 
>> In both of the above cases, idea in our draft works. 
>  
> The issue is further down in that section:
>  
>   One other fragmentation technique discussed was splitting the IP
>   datagram into approximately equal sized IP fragments, with the
>   size less than or equal to the next hop network's MTU. ...
>  
> In that case, none of the fragments gives you the path MTU.
>  
> Joe 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 the end of sec 1 is relevant, but given v4-in-v4 
>>> tunneling, it?s possible that 
>>> paths might be smaller than the 576 assumption)
> 
> We use an unused field in first 8 bytes of ICMP error/reply message.

Please explain. Most ICMP messages have 4 bytes of unused field, but not all 
(one has only 3).

> How the idea would be
> affected if minimum packet size is 68 bytes or 576 bytes. As per my 
> understanding,
> existing ICMP error/reply message works in v4-in-v4 tunnelling, so it would 
> continue to 
> work with the idea proposed in our draft. we won’t let the ICMP message 
> exceed a reasonable size. 
> in our implementation, that will be 576.

Sending the largest response possible given an untunneled MTU size is an 
invitation to black-hole the response itself if (when) an IPv4-in-IPv4 tunnel 
is encountered.

In most situations, ICMP responses are received from small initial messages 
that don’t stress that limit. The use in this doc is the opposite - it relies 
on ongoing use of ICMP for max-sized packets and returns max-sized payloads. 
This isn’t helpful. It would be more useful to try to limit the size to the 
minimum expected to be useful and account for these other encapsulations.

> 
>>> - why would this approach find the largest fragment through a system?
>>>  rfc1812 talks about various strategies, one of which is ?equal sized?, 
>>> which might never find 
>>> the max the way you propose
> 
> 
> As per section 4.2.2.7 from rfc 1812,
> 
> “There are several fragmentation techniques in common use in the
> Internet.  One involves splitting the IP datagram into IP
> fragments with the first being MTU sized, and the others being
> approximately the same size, smaller than the MTU. “
> 
> In both of the above cases, idea in our draft works.

The issue is further down in that section:

  One other fragmentation technique discussed was splitting the IP
  datagram into approximately equal sized IP fragments, with the
  size less than or equal to the next hop network's MTU. ...

In that case, none of the fragments gives you the path MTU.

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 only benefit. 

Joe

On 2019-11-01 09:04, Templin (US), Fred L wrote:

>> A different title might be better.
> 
> Call it "Report Fragmentation". Have the receiver check the RF bit to see if 
> the sender
> wants fragmentation reported. If so, send the report; else, just reassemble 
> as normal.
> 
> Fred
> 
> -Original Message-
> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Bob Hinden
> Sent: Thursday, October 31, 2019 4:51 PM
> To: Ron Bonica 
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] New Version Notification for 
> draft-bonica-intarea-lossless-pmtud-01.txt
> 
> Ron,
> 
> A few comments on your draft.
> 
> Naming the draft "Lossless Path MTU Discovery (PMTUD)" seems to be very 
> aspirational, and is an oxymoron.  ICMP message can be
> rate limited and dropped in the network.   Hardly "lossless".  A different 
> title might be better.
> 
> I do like the idea of the destination sending feedback, we have worked on 
> some other drafts with that property.
> 
> The document says:
> 
> This document describes alternative PMTUD procedures that do no rely
> on the network's ability to deliver ICMP Destination Unreachable
> messages to the source node.  In these procedures, the source node
> produces an initial PMTU estimate.  This initial estimate is equal to
> the MTU of the first link along the path to the destination node.  It
> can be greater than the actual PMTU.
> 
> This is not really correct, your are still dependent on the networks ability 
> to deliver ICMP messages to the source node.  Just not ICMP
> Destination Unreachable messages.   A new ICMP message isn't going to be 
> better, perhaps worse.
> 
> I didn't understand the purpose of the Code field, that can indicate 
> reassembly error.  What is the purpose of this?   This seems to be
> in conflict with this message that is sent when the destination node 
> successfully reassemblies a set of fragments.  With the code
> indicating reassembly error, it is saying that the fragments were not 
> reassembled.
> 
> 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.
> 
> I see you have several co-authors from Harvey Mudd College.
> 
> Bob
> 
> On Oct 31, 2019, at 12:16 PM, Ron Bonica 
>  wrote:
> 
> Updated draft
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Thursday, October 31, 2019 3:15 PM
> To: Ron Bonica ; Hakan Alpan ; Radon 
> Rosborough ; Bradely Newton ; Bradley 
> Newton ; Miles President ; Manoj Nayak
>  Subject: New Version Notification for 
> draft-bonica-intarea-lossless-pmtud-01.txt
> 
> A new version of I-D, draft-bonica-intarea-lossless-pmtud-01.txt
> has been successfully submitted by Ron Bonica and posted to the IETF 
> repository.
> 
> Name:draft-bonica-intarea-lossless-pmtud
> Revision:01
> Title:Lossless Path MTU Discovery (PMTUD)
> Document date:2019-10-31
> Group:Individual Submission
> Pages:7
> URL 
> https://tools.ietf.org/html/draft-bonica-intarea-lossless-pmtud-01
> Abstract:
> This document describes alternative IPv4 PMTUD procedures that do not
> prevent IP fragmentation and do no rely on the network's ability to
> deliver ICMP Destination Unreachable messages to the source node.
> This document also defines a new ICMP message.  IPv4 nodes emit this
> new message when they reassemble a fragmented packet.
> 
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org. 
> The IETF Secretariat
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 hill, but I doubt 
> you will be successful.
> 
> BTW, what *actually* prevents a middlebox from doing IPv6 fragmentation? 
> Expecting it to work. That middlebox has no idea what packets are going 
> through other middleboxes from the same endpoint. There's no way it can pick 
> IDs to avoid collision, the way the origin can. That's why both IPv4 and IPv6 
> rely on the origin creating those IDs.
> 
> The result would either be significantly increased reassembly errors, sort of 
> like accidental poisoning of the receiver's cache, or potentially resulting 
> in incorrect packets (the latter could be more likely in some cases, e.g., 
> when the fragment happens to have a zero IP checksum).

I don't especially disagree with you, BUT...

Thinking about middlebox fragmentation. OK, suppose I am a company with
N middleboxen. Suppose I configured the middleboxes to generate N
disjoint ranges of IDs. If I have a datagram arriving at a middle box
and being fragmented into two or more, and the ID generated is within
the range assigned to the middle box, I don't think the results you
predict actually transpire. 

Yes - but that's exactly the point. You can't know you are the only such
middlebox. 

I.e., my general rule about middleboxes is that they work ONLY when ALL
the middleboxes on a path from A to B can act as a single proxy for
either A or B. That works at the edge of an enterprise (firewalls setup
around an enterprise perimeter) but nearly nowhere else. 

> Note that I'm not writing a draft about that. I'm not sure I want anyone 
> thinking it's a great idea and needs to be implemented.

Glad to hear that, though. 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 IPv6 fragmentation? 

Expecting it to work. That middlebox has no idea what packets are going through 
other middleboxes from the same endpoint. There’s no way it can pick IDs to 
avoid collision, the way the origin can. That’s why both IPv4 and IPv6 rely on 
the origin creating those IDs.

The result would either be significantly increased reassembly errors, sort of 
like accidental poisoning of the receiver’s cache, or potentially resulting in 
incorrect packets (the latter could be more likely in some cases, e.g., when 
the fragment happens to have a zero IP checksum).

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 ICMPs, so it’s as robust (or, more to the point, not) 
as PMTUD
if ICMPs can find the reverse path from the dest, why wouldn’t the 
routers?
i.e., isn’t the problem with ICMPs not just routers not sending them 
but firewalls BLOCKING them?
(i.e., if ICMPs would work here, PMTU would have worked, rendering this 
unnecessary)

- 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 the end of sec 1 is relevant, but given v4-in-v4 
tunneling, it’s possible that paths might be smaller than the 576 assumption)

- why would this approach find the largest fragment through a system?
rfc1812 talks about various strategies, one of which is “equal sized”, 
which might never find the max the way you propose 


> On Oct 29, 2019, at 9:53 AM, Ron Bonica 
>  wrote:
> 
> Folks,
> 
> Please review and comment.
> 
>Ron
> 
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: internet-dra...@ietf.org  
> Sent: Tuesday, October 29, 2019 11:48 AM
> To: Ron Bonica ; Hakan Alpan ; Radon 
> Rosborough ; Bradely Newton ; Miles 
> President ; Manoj Nayak 
> Subject: New Version Notification for 
> draft-bonica-intarea-lossless-pmtud-00.txt
> 
> 
> A new version of I-D, draft-bonica-intarea-lossless-pmtud-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF 
> repository.
> 
> Name: draft-bonica-intarea-lossless-pmtud
> Revision: 00
> Title:Lossless Path MTU Discovery (PMTUD)
> Document date:2019-10-29
> Group:Individual Submission
> Pages:8
> URL:
> https://tools.ietf.org/html/draft-bonica-intarea-lossless-pmtud-00
> 
> 
> 
> Abstract:
>   This document describes alternative IPv4 PMTUD procedures that do not
>   prevent IP fragmentation and do no rely on the network's ability to
>   deliver ICMP Destination Unreachable messages to the source node.
>   This document also defines a new ICMP message.  IPv4 nodes emit this
>   new message when they reassemble a fragmented packet.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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:
>> 
>> Dear Authors, et al.,
>> I have a rather benign question the new registry requested in Section 8.3. 
>> The draft states that the whole 1-127 range is "RFC required" per RFC 5226. 
>> Firstly, a nit - RFC 5226 has been obsoleted by RFC 8126. My question is 
>> Would you agree to split the 128-255 range and set First Come First Served 
>> sub-range. For example:
> 
> Please explain why you are proposing this change.
> 
> Thanks,
> Bob
> 
> 
>>  ++--+---+
>>  |  Control type  | Description  | Reference |
>>  ++--+---+
>>  | 0  | Control payload  | This document |
>>  || needs more   |   |
>>  || context for  |   |
>>  || interpretation   |   |
>>  ||  |   |
>>  | 1..127 | Unassigned   |   |
>>  ||  |   |
>>  | 128..250   | First Come   | RFC 8126  |
>>  || First Served |   |
>>  | 251..254   | Experimental | This document |
>>  ||  |   |
>>  | 255| Reserved | This document |
>>  ||  |   |
>>  ++--+---+
>> 
>> Also, you may consider updating 0 as Reserved and assigning 1 as Control 
>> payload ...
>> Much appreciate your consideration.
>> 
>> Regards,
>> Greg
>> 
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> ___
> Int-area mailing list
> Int-area@ietf.org 
> https://www.ietf.org/mailman/listinfo/int-area 
> 
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 be the case, 
> does not necessarily hold true in present or the future. 

Sure, but...

> Back in the hackathon at IETF 100 we even showcased a hardware implementation 
> of what is ultimately an extension header use-case, see e.g. 
> https://www.globenewswire.com/news-release/2017/11/10/1195153/0/en/Barefoot-Networks-Collaborates-with-Cisco-to-Demonstrate-In-situ-Operations-Administration-and-Management-IOAM-Showcasing-the-Power-of-Programmable-Forwarding-Plane-Technology.html
>  
> 
> Providing a holistic implementation in hardware for recent efforts that 
> leverage EH (like PDM, IOAM, etc.) would become easier if we had a protocol 
> independent approach to EH. This would mean that e.g. for IOAM we could use 
> almost the same implementation for v4 as we'd do for v6

I think you’re missing Bob’s point, which I’ll expand on:

a) you can already proceed for IPv6; show us it has been deployed

b) as you note, IPv4 != IPv6. “almost the same” has a lot of variants...

> - protocol specific efforts would be limited, and as a nice side effect we'd 
> avoid more complex encapsulations for IOAM in IPv4 which we'd need to use 
> otherwise (e.g. one proposal is to use GRE - which doesn't make things 
> easier).

I can see how GRE might be more complex, but not why a HBH code point is needed 
(e.g., vs. just an IPv4 protocol code point and using the IPsec approach).

Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 
> network, 68/distributed FS, 99/private encryption scheme, 114/0-hop).

For the same reasons Bob mentions, I think this isn’t needed.

We don’t need to encourage playing with these code points for experiments; 
better a protocol designer go through the standards-track process, at which 
point they can either use one of these codepoints or get a new one.

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

Hi, David,

Although I appreciate new interest in trying this experiment, that’s not what I 
was asking.

My understanding of the logic is as follows:
- IPv4 in-header options aren’t supported
- so let’s make a version of IPv4 options inspired by IPv6 HBH options

That logic only works if IPv6 HBH options were a success. I’m asking for anyone 
to point to a success case.

If there are no widely deployed IPv6 HBH options at this point (given they’ve 
been available for two decades), this is not a useful approach to mimic in IPv4.

Joe

> On Sep 27, 2019, at 7:11 AM, Black, David  wrote:
> 
> There may be a relatively contained early-adopter opportunity to try 
> something in this area of IPv4 options – Deterministic Networking (DetNet – 
> detnet WG) is using 6-tuple match (2 x IP address, L4 protocol [e.g., TCP, 
> UDP], 2 x port, DSCP) to pick off traffic flows that go through the DetNet 
> data plane in routers instead of the default data plane.  DetNet appears to 
> nee IOAM in order to ensure that OAM traffic goes through the DetNet data 
> plane – if the DetNet data plane is down, having an OAM  continuity check 
> report 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
> Sent: Thursday, September 26, 2019 11:17 AM
> To: Tom Herbert
> Cc: int-area
> Subject: Re: [Int-area] New Version Notification for 
> draft-herbert-ipv4-hbh-destopt-00.txt
>  
> [EXTERNAL EMAIL] 
> 
> Hi, Tom,
> 
> 
> On Sep 26, 2019, at 7:54 AM, Tom Herbert  <mailto:t...@herbertland.com>> 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 
> that it *has*.
>  
> I.e., I’m following your logic:
>   - IPv4 options are not deployed and so are not useful
>  
> I agree completely. But isn’t the same true for IPv6 HBH?
>  
> If not, can you provide *an example of a widely deployed HBH option in 
> current use*?
> 
> 
> Last time I checked, Hop-by-Hop options have not been deprecated by IETF. 
> Neither do I see why it's incumbent on us to show they're widely deployed as 
> a prerequisite to developing them. Additionally, what is the evidence that 
> they're not widely deployed-- for instance do we _know_ for a fact that 
> they're not deployed in some large private network? (IOAM is targeted to 
> closed networks). For that matter if we only are allowed to work with 
> protocols that are widely deployed, then how could we ever work on new 
> protocols? E.g. why should we develop new UDP options when they currently 
> they have no deployment.
>  
> Agreed, but your logic leads to the conclusion that you should be using IPv4 
> options (unless you show that space is a problem) first.
>  
> If that is a problem, then an IP protocol is sufficient, as it was for IPsec.
>  
> I see no need for an IPv4 framework to address a problem that doesn’t need 
> that *framework*.
>  
> Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 that it *has*.

I.e., I’m following your logic:
- IPv4 options are not deployed and so are not useful

I agree completely. But isn’t the same true for IPv6 HBH?

If not, can you provide *an example of a widely deployed HBH option in current 
use*?

> Last time I checked, Hop-by-Hop options have not been deprecated by IETF. 
> Neither do I see why it's incumbent on us to show they're widely deployed as 
> a prerequisite to developing them. Additionally, what is the evidence that 
> they're not widely deployed-- for instance do we _know_ for a fact that 
> they're not deployed in some large private network? (IOAM is targeted to 
> closed networks). For that matter if we only are allowed to work with 
> protocols that are widely deployed, then how could we ever work on new 
> protocols? E.g. why should we develop new UDP options when they currently 
> they have no deployment.

Agreed, but your logic leads to the conclusion that you should be using IPv4 
options (unless you show that space is a problem) first.

If that is a problem, then an IP protocol is sufficient, as it was for IPsec.

I see no need for an IPv4 framework to address a problem that doesn’t need that 
*framework*.

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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* deployed this way at line rate in hardware 
>> (notably not for experiments or diagnostic debugging)?
>>(NB: I don’t consider tunnel encapsulation/decap or IPsec useful 
>> examples; those can already be
>>supported that way and don’t really need this “option” mechanism; 
>> frag isn’t useful either)
>> 
> Joe,
> 
> The use case for this is the same as that for IPv6 HBH and DestOpts.

My concern is that the HBH options are not used largely for the same reasons 
that IP options are not used:
a) they are not cost-effective to implement in the fast path
b) slow-path processing is not considered useful.

> There is a need in IPv4 to carry optional network layer information
> that might be inspected and possibly modified (HBH options at least).

That’s called a packet. If routers actually didn’t look further inside without 
explicit permission of a HBH header, I’d agree. But they routinely dig far into 
packets for their own purposes, often at the expense of E2E integrity or 
semantics.

> IOAM is a very good example

It’s a pending example; if you can show no widely deployed and used IPv6 HBH 
header, then this all becomes speculation.
…
> Defining an IOAM protocol for IPv4 is the problem. There are at least
> five proposals:
> 
> 1) Use IPv4 options to carry the data (e.g. IPv4+options->TCP)
> 2) Allocate a new IP protocol number to carry IOAM data (IPv4->IOAM->TCP)
> 3) Embed IOAM data in the optional data of a UDP encapsulation like
> Geneve or GUE (IPv4->UDP->GUE->TCP)
> (draft-brockners-ippm-ioam-geneve-03)
> 4) Use GRE and create a new EtherType that contain IOAM data structure
> (IPv4->GRE->IOAM->TCP) (draft-weis-ippm-ioam-gre-00)
> 5) Enable Hop-by-Hop options in IPv4 and use the IOAM HBH option being
> defined (IPV4->HBH->TCP) (this draft)
> 
> #1 is the standard way to extend IPv4 for this sort of thing, however
> IPv4 are generally considered a non-starter. It's well known that
> routers don't deal with them well and the space is limited to forty
> bytes.

Is space an issue for IOAM?
And if routers don’t do IP options, why do you think they would handle IOAM?

> #2 would define a new type of extension header.

This seems easily sufficient - the argument that it’s hard to get an IP 
protocol number is correct - it should be. But isn’t that what you’re doing 
with this draft? Wouldn’t needing an IP protocol number still be needed even if 
your draft passed?

I.e., why do we need to do double the assignment and work - esp. given this is 
for an emerging proposal.

> #3 isn't robust
> because modifying UDP payload in the network leads to silent data
> corruption when the UDP ports are misinterpreted (RFC7605).

Agreed - a port filter would then disable this approach. But why isn’t that a 
*desirable* property? IMO, this protocol represents a potential security risk 
that should be easy for users or networks to disable and filter.

> #4 is interesting. There is a certain appeal in that it's much easier
> to get an EtherType allocation rather than an IP protocol number.
> OTOH, this seems like an abuse of GRE to turn it into IP extensibility
> mechanism which it was never intended to be.

Arguably you’re doing the same with the IP protocol field, but then (as noted 
before), IPsec already did this.

> #5 is the proposed method of this draft.
> 
> Assuming that IPv4 options are not an option, all the remaining share
> some properties. Each is creating or using an extension header in some
> format (i.e. a header inserted between the IPv4 header and transport
> layer). They are all subject to IPv4 fragmentation where fragments
> will not contain the IOAM data-- the first fragment may contain IOAM
> data and it would need to be specified whether intermediate nodes can
> process the data.
> 
> Tom
> 
> 
> Th#2-#5 are variations on the same theme, namely to carry IOAM data in
> some sort of extension header. The differences amongst these are the
> format the extension header would take.
>> Joe
>> 
>>> On Sep 24, 2019, at 11:58 AM, Tom Herbert  wrote:
>>> 
>>> Hello,
>>> 
>>> I posted a new draft on allowing Hop-by-Hop and Destination options in
>>> IPv4. Relative to the previous draft on IPv4 extension headers
>>> (draft-herbert-ipv4-eh-01) this draft is narrow in intent to just
>>> define use of HBH and DestOpt in IPv4 based on feedback during
>>> IEFT104.
>>> 
>>> Thanks,
>>> Tom
>

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

[Joe Touch]

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 copied into each fragment when fragmented

note that this means that an extended discussion of how to fragment and 
its implications is needed;
the standard alg won’t work. it also means you’ll strictly exceed the 
IPv4 official definitions of MTU and
minimum frag size.

however, this complicates the claim that HBH options in the first frag 
are handled only if they’re
complete; if they’re not complete, you have no protocol left

i.e., either HBH are copied into EACH FRAGMENT (as they are at the 
source in IPv6), or 
fragmentation CANNOT occur; you can’t simply act as if the HBH happens 
only for the first
fragment or are ignored at IP hops other than the destination

(FWIW, it’s the second point that leads me to question the utility here)

- that said, why is this supposed to help? can you give us examples of 
successful IPv6 *options* deployed this way at line rate in hardware (notably 
not for experiments or diagnostic debugging)?
(NB: I don’t consider tunnel encapsulation/decap or IPsec useful 
examples; those can already be
supported that way and don’t really need this “option” mechanism; frag 
isn’t useful either)

Joe

> On Sep 24, 2019, at 11:58 AM, Tom Herbert  wrote:
> 
> Hello,
> 
> I posted a new draft on allowing Hop-by-Hop and Destination options in
> IPv4. Relative to the previous draft on IPv4 extension headers
> (draft-herbert-ipv4-eh-01) this draft is narrow in intent to just
> define use of HBH and DestOpt in IPv4 based on feedback during
> IEFT104.
> 
> Thanks,
> Tom
> 
> 
> -- Forwarded message -
> From: 
> Date: Tue, Sep 24, 2019 at 11:53 AM
> Subject: New Version Notification for draft-herbert-ipv4-hbh-destopt-00.txt
> To: Tom Herbert 
> 
> 
> 
> A new version of I-D, draft-herbert-ipv4-hbh-destopt-00.txt
> has been successfully submitted by Tom Herbert and posted to the
> IETF repository.
> 
> Name:   draft-herbert-ipv4-hbh-destopt
> Revision:   00
> Title:  IPv4 Hop-by-Hop Options and Destination Options
> Extension Headers
> Document date:  2019-09-24
> Group:  Individual Submission
> Pages:  18
> URL:
> https://www.ietf.org/internet-drafts/draft-herbert-ipv4-hbh-destopt-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-herbert-ipv4-hbh-destopt/
> Htmlized:   https://tools.ietf.org/html/draft-herbert-ipv4-hbh-destopt-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-hbh-destopt
> 
> 
> Abstract:
>   This specification enables the use of Hop-by-Hop Options and
>   Destination Options extension headers which are defined for IPv6 to
>   be used with IPv4. The goal is to provide a uniform and feasible
>   method of extensibility that is common between IPv4 and IPv6.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 also use it.
>> 
>> That means that it might be useful to treat that protocol a little like the 
>> experimental TCP codepoints as per RFC6994, i.e., to include a long (4-byte 
>> minimum) magic number and tolerate collisions.
> 
> Or add a protocol number following this ambiguous protocol number.
> 
> (See what I did there?)

Sure, that’s what the ID does - but it’s also a value that’s presumably 
unlikely to come up otherwise (that’s why it’s not just a single byte).

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 also use it.

That means that it might be useful to treat that protocol a little like the 
experimental TCP codepoints as per RFC6994, i.e., to include a long (4-byte 
minimum) magic number and tolerate collisions.

Joe

> On Sep 20, 2019, at 9:03 PM, Erik Kline  wrote:
> 
> There's also the matter of whether allocating 114 for this doc would 
> establish a precedent.
> 
> On Fri, 20 Sep 2019 at 20:24, Brian E Carpenter  <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 chance they are installed 
> on a layer 2 segment where it is in use. So even if no traces anywhere 
> include it for ten years, we still can't assert that it is out of use. It 
> seems harder to prove than most negatives :-).
> 
> > 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 those dead entries.
> > 
> > So the net effect is:
> > a) the list will never actually reflect what is deployed (as Bob notes 
> > below)
> > b) garbage-collecting will at best mark some subset as dead
> > c) but the available entries won’t be reused until we run out anyway
> > 
> > Given the number of remaining entries, the task of garbage collection seems 
> > of little value.
> 
> Until the day when it seems urgent...
> 
> Brian
> 
> > 
> > Joe
> > 
> >> On Sep 20, 2019, at 1:31 PM, Bob Hinden  >> <mailto:bob.hin...@gmail.com>> wrote:
> >>
> >> Andy,
> >>
> >>> On Sep 20, 2019, at 10:37 AM, Andrew G. Malis  >>> <mailto:agma...@gmail.com>> wrote:
> >>>
> >>> Behcet,
> >>>
> >>> That was a historical list. The current assignments are in 
> >>> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml 
> >>> <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml>
> >>>  . If you want to go garbage collecting, that's the place to start.
> >>
> >> It's difficult to tell which are no longer used.  For example, I was 
> >> recently asked about the Reliable Data Protocol, it’s IANA assignment:
> >>
> >> 27   RDP Reliable Data Protocol  [RFC908][Bob_Hinden]
> >>
> >> I assumed it was no longer used.   Later by happenstance, I learned it is 
> >> specified by ETSI as mandatory to implement in eSIMs.  I had no idea.
> >>
> >> Bob
> >>
> >>
> >> ___
> >> internet-history mailing list
> >> internet-hist...@mailman.postel.org 
> >> <mailto:internet-hist...@mailman.postel.org>
> >> http://mailman.postel.org/mailman/listinfo/internet-history 
> >> <http://mailman.postel.org/mailman/listinfo/internet-history>
> >> Contact list-ow...@mailman.postel.org 
> >> <mailto:list-ow...@mailman.postel.org> for assistance.
> > 
> > ___
> > internet-history mailing list
> > internet-hist...@mailman.postel.org 
> > <mailto:internet-hist...@mailman.postel.org>
> > http://mailman.postel.org/mailman/listinfo/internet-history 
> > <http://mailman.postel.org/mailman/listinfo/internet-history>
> > Contact list-ow...@mailman.postel.org 
> > <mailto:list-ow...@mailman.postel.org> for assistance.
> > 
> 
> ___
> Int-area mailing list
> Int-area@ietf.org <mailto:Int-area@ietf.org>
> https://www.ietf.org/mailman/listinfo/int-area 
> <https://www.ietf.org/mailman/listinfo/int-area>

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 those dead entries.

So the net effect is:
a) the list will never actually reflect what is deployed (as Bob notes below)
b) garbage-collecting will at best mark some subset as dead
c) but the available entries won’t be reused until we run out anyway

Given the number of remaining entries, the task of garbage collection seems of 
little value.

Joe

> On Sep 20, 2019, at 1:31 PM, Bob Hinden  wrote:
> 
> Andy,
> 
>> On Sep 20, 2019, at 10:37 AM, Andrew G. Malis  wrote:
>> 
>> Behcet,
>> 
>> That was a historical list. The current assignments are in 
>> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml . 
>> If you want to go garbage collecting, that's the place to start.
> 
> It's difficult to tell which are no longer used.  For example, I was recently 
> asked about the Reliable Data Protocol, it’s IANA assignment:
> 
> 27RDP Reliable Data Protocol  [RFC908][Bob_Hinden]
> 
> I assumed it was no longer used.   Later by happenstance, I learned it is 
> specified by ETSI as mandatory to implement in eSIMs.  I had no idea.
> 
> Bob
> 
> 
> ___
> internet-history mailing list
> internet-hist...@mailman.postel.org
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact list-ow...@mailman.postel.org for assistance.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 might not have a 
transport header

I.e., how does this move the needle forward?

Joe

> 
>> On Sep 13, 2019, at 2:59 PM, Ole Troan  wrote:
>> 
>> Fred,
>> 
>>> 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 produce a new link-layer, that can (should) be a 
>> function of that link-layer.
>> Network layer fragmentation is not needed for that.
>> (For the purpose of making the point and to set future direction, ignoring 
>> existing IP tunnel mechanisms).
>> 
>> Cheers,
>> Ole
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 produce a new link-layer, that can (should) be a 
> function of that link-layer.
> Network layer fragmentation is not needed for that.
> (For the purpose of making the point and to set future direction, ignoring 
> existing IP tunnel mechanisms).


IP in IP tunneling is the point here. It’s both a standard and widely used.

What’s the point of omitting it or setting that as a direction?

Joe



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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
>>>   fragmentation in order to forward the 1280 byte IPv6 packets.
>> 
>> Yes, IP fragmentation - exactly.
> 
> See also Section 7 of RFC2473.

There are a number of issues with that RFC, as noted in intarea-tunnels.

E.g., it won’t properly do what you say for IPv4 DF=0 (i.e., treat the tunnel 
as a true link layer by allowing frag at the tunnel header), nor will it 
correctly interconnect two hosts for packets with TTL/hopcounts fo 0 (which 
should work - only routers should decrement those).

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 IPsec tunnel mode), ends up then requiring 
fragmentation. There’s no way around that - once there’s a required minimum and 
once it’s recursive, the game is over.

(BTW, the only thing that bails you out is to then ensure you have 
fragmentation and that the receiver reassembly minimum is large enough to cover 
two fragments, one as large as you can fit as a payload and the other that fits 
a payload at least as large as the rest of the MTU).

Joe

> On Sep 10, 2019, at 3:53 PM, Geoff Huston  wrote:
> 
> 
>>> 
>>> This would seem to be incorrect. IP has a minimum MTU of 68 bytes, and
>>> IPv6 has a minimum MTU of 1280. Hence if you send packets smaller than
>>> or equal to the minimum MTU, the packets should go through.
>> 
>> Even if the original source uses the IPv6 minimum MTU of 1280, a tunnel 
>> somewhere
>> further down the path could add encapsulations that would cause the 
>> (encapsulated)
>> packet to exceed 1280 bytes. The tunnel therefore has to apply fragmentation.
> 
> I hesitate to venture into this thread but I did a bit of digging around in 
> the mail archives some time ago to figure out “why 1280?” as the IPv6 MTU. 
> The desire was to lift the minimum unfragmented packet from 64 bytes (IPv4) 
> to something that would reflect what was possible that would all but 
> eliminate the need for fragmentation in IPv6. But at the same time there was 
> the awareness of various forms of encapsulation and the possibility of 
> multiple levels. 1500 octets was taken as the stating point and in the end 
> 1280 was proposed. Why 1280? Because its the number you get when you add 1024 
> and 256. However, it expressed a basic idea that 1480 (IPv6 in IPv4), 1460 
> (IPv6 in IPv6), or any other number ‘close’ to 1500 could not. It allowed for 
> almost any form of encapsulation of an IPv6 packet that we would be likely to 
> see and the result would still  be within the 1500 ethernet framing limit and 
> hence avoid a path MTU mismatch. From this starting point it is odd odd to 
> see an argument about packet size that _starts_ with 1280 as some lower level 
> media-related packet limit (it isn’t) and then applies encapsulation models 
> on this. If we really are going to go through such an exercise then it would 
> be more realistic to start with the number 1500 and apply encapsulation to 
> that number. 
> 
> Secondly, it is interesting to look at what IPv6 stacks actually do with 
> local MTU values. Do they all use 1280? nope! The most common value is 1430. 
> (see http://www.potaroo.net/ispcol/2019-07/mss.html) 
> 
> So I personally don't see any practical value in this line of logic that 
> says: "start with a source using a MTU of 1280 and apply encapsulation”
> 
> But I’ve said enough - I’m heading back back to lurking in this rather 
> protracted and messy thread.
> 
> g
> 
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

+1

You have no  way of knowing how many tunnels are being traversed.

There is no packet size that *guarantees* you have avoided fragmentation 
somewhere along an Internet path.

Joe

> On Sep 10, 2019, at 6:29 AM, Templin (US), Fred L  
> wrote:
> 
> Fernando,
> 
>> -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 
>> Subject: Re: [Int-area] Discussion about Section 6.1 in 
>> draft-ietf-intarea-frag-fragile
>> 
>> Hi, Joe,
>> 
>> Just one nit:
>> 
>> On 7/9/19 20:35, Joe Touch wrote:
>>> 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 the connected interface*. There’s no way to 
>>> disable source fragmentation that happens later in the
>> network (as it would at tunnel ingresses) or deeper in the stack (when what 
>> you think is your interface is locally tunneled over a layer
>> you don’t even know about).
>>> 
>>> So *all* systems that try to backoff and use smaller MTUs are actually 
>>> *already* testing whether fragmentation already works in
>> those cases. Even if your app sends a 1-byte packet you have no idea that 
>> some set of layers inflates the headers (e.g., with
>> signatures or key exchanges) beyond the MTU somewhere.
>> 
>> This would seem to be incorrect. IP has a minimum MTU of 68 bytes, and
>> IPv6 has a minimum MTU of 1280. Hence if you send packets smaller than
>> or equal to the minimum MTU, the packets should go through.
> 
> Even if the original source uses the IPv6 minimum MTU of 1280, a tunnel 
> somewhere
> further down the path could add encapsulations that would cause the 
> (encapsulated)
> packet to exceed 1280 bytes. The tunnel therefore has to apply fragmentation.
> 
> Fred
> 
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fg...@si6networks.com
>> PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> 
>> 
>> 
>> 
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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:
>>> 
>>>>> 
>>>>> 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 Report | Links | BibTeX)
>>>> 
>>>>  * https://www.strayalpha.com/pubs/isi-tr-711.pdf
>>> 
>>> I'll take the liberty of pointing out that we've known for many years that
>>> there are multiple types of middleboxes and they have multiple facets:
>>> https://tools.ietf.org/html/rfc3234
>> 
>> Facets are just properties. That doc makes no attempt to describe them as 
>> architectural roles.
> 
> Agreed. My point is that the issue has been lying on the IETF table for many 
> years, and we've collectively chosen to ignore it.

By “we”, I’m not sure who you mean. There have been plenty of us complaining 
about this gap for a very long time in the IETF.

> 
>>> 
>>> So far, we haven't added them to any formal architectural description of
>>> the Internet, probably because we don't have one.
>> 
>> RFC1122, RFC1123, RFC1812 as standards.
>> 
>> I (and IMO those RFCs) disagree with the position you took in RFC1958, FWIW.
> 
> "you" = the IAB in 1996; I was only the document editor.

Fair point, but presumably you were on the IAB at the time?

> But IMHO those RFCs are not architectural as such. They describe functions of 
> nodes, not how the nodes work together as a system.

An architecture is (IMO) the behavior of a system that is the consequence of 
the behavior of its components and the ways in which they interact.

Arguably, those RFCs - adding 791 and 3819, and a few others, do exactly that. 
In a nutshell: routers relay; subnets (as links) interconnect), and hosts 
source, sink, and do the rest (including reliability), all based on 
globally-unique addresses in that can be aggregated by bit prefix. No, there’s 
no “roadmap” doc that provides the top-level description, but the rest is 
definitely there in those and other docs.

IMO, the issue is that middleboxes can’t simply be added to that list 
consistently - they aren’t a third thing that can be peers to routers or hosts. 
There is a way to describe them that’s consistent, though - but only if they 
are different elements when viewed from different points in the network (as I 
described in the tech report). 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 Report | Links | BibTeX)
>> 
>>  * https://www.strayalpha.com/pubs/isi-tr-711.pdf 
>> 
> 
> I'll take the liberty of pointing out that we've known for many years that
> there are multiple types of middleboxes and they have multiple facets:
> https://tools.ietf.org/html/rfc3234 

Facets are just properties. That doc makes no attempt to describe them as 
architectural roles.

> 
> So far, we haven't added them to any formal architectural description of
> the Internet, probably because we don't have one.

RFC1122, RFC1123, RFC1812 as standards.

I (and IMO those RFCs) disagree with the position you took in RFC1958, FWIW.

Joe


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 the connected interface*. There’s no way to 
disable source fragmentation that happens later in the network (as it would at 
tunnel ingresses) or deeper in the stack (when what you think is your interface 
is locally tunneled over a layer you don’t even know about).

So *all* systems that try to backoff and use smaller MTUs are actually 
*already* testing whether fragmentation already works in those cases. Even if 
your app sends a 1-byte packet you have no idea that some set of layers 
inflates the headers (e.g., with signatures or key exchanges) beyond the MTU 
somewhere.

Thus claiming that “fragmentation must be avoided at all costs” is simply not 
even possible anyway. That’s why it’s reasonable to bring encapsulation up. It 
works - even when you don’t know.

Joe

> On Sep 7, 2019, at 10:25 AM, Bob Hinden  wrote:
> 
> Ole,
> 
>> On Sep 6, 2019, at 9:03 AM, Ole Troan  wrote:
>> 
>> 
>> This document should not recommend IP in UDP in IP encapsulation to achieve 
>> end to end IP fragmentation for new applications.
> 
> The document doesn’t say that, nor is the document recommending this.  The 
> current text Joe and I proposed to the list was:
> 
>  The risks of IP fragmentation can also be mitigated
>  through the use of encapsulation, e.g., by transmitting IP fragments
>  as payloads.
> 
> If this was recommended it would have included the word “recommended” or 
> SHOULD/MUST terminology.
> 
> It’s only mentioning this, along with other approaches, as a possible 
> approach for mitigating the problems.
> 
> Bob
> 
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 deleting.
>> 
>> Fragmentation success or failure is directly testable. Any feedback 
>> mechanism will work and specific ones are mentioned elsewhere (PLPMTUD).
>> 
>> This differs from ICMP black-holing in path MTU detection.
> 
> Can you please point me to where in the PLPMTUD document testing for IP 
> fragmentation is described?
 
 Any feedback mechanism will detect when fragmentation - or anything else - 
 prevents delivery.
>>> 
>>> Any pointer to such a mechanism in any IETF protocol?
>>> Would be interesting to get transport/application perspective on this.
>>> But unless there is a reference I would claim this is hand-waving.
>> 
>> As I said, PLPMTUD. It doesn’t have to detect if there’s a layer of 
>> fragmentation it can’t detect; it figures out for itself that a given MTU 
>> doesn’t succeed and sends a smaller MTU.
> 
> Sorry, I still don't understand how PLPMTUD detects if fragmentation works 
> reliably or not.
> 
> The paragraph we are disccusing is:
>  "Protocols and applications that rely on IP
>  fragmentation will work less reliably on the Internet unless they
>  also include mechanisms to detect that IP fragmentation isn't working
>  reliably."
> 
> My view is that unless we can point to a reference or specification for how 
> to do this, then it amounts of hand waving.

It’s a homework assignment in a 1st yr net class.

*Any* two-way protocol gets feedback as to whether it works.

If you send large packets and they work, you’re done.

If not, you have to backoff and fragment at the app layer - which is less 
efficient, but will still get through.

—

ANY protocol that can adjust to an MTU based on feedback CAN try larger MTUs 
than the first hop link reports and see if they work.

> And possibly sending application developers out on a wild goose chase.
> And given that applications would have to work in the cases where 
> fragmentation was found to not work reliably…

They have to do this anyway, but this way they don’t have to be stuck with 
app-layer fragmentation when the network can to it instead.

> 
 If you fragment and put the result inside GRE or UDP, the impact of the 
 fragment (interfering with flow-based multi path routing, nat traversal, 
 etc) is overcome.
>>> 
>>> Sure, but that only applies to tunnels that go end to end.
>> 
>> It applies to tunnels that traverse wherever fragmentation is both needed 
>> and doesn’t work other ways.
>> 
>> Speaking of deployed mechanisms, it’s also how IPsec tunnels over UDP 
>> already work and are widely deployed.
> 
> It does not work.
> Host A -- ipsec tunnel -- SGW -- Host B
> 
> 1) If host A sends fragments inside of the tunnel to host B, the fragments 
> are equally fragile between the security gateway and host B.

It’s not equally fragile. Fragments inside UDP overcome NATs and ECMP that 
(incorrectly) refuse to support packets without transport headers.

….
> 
>>> ...This document should not recommend IP in UDP in IP encapsulation to 
>>> achieve end to end IP fragmentation for new applications.
>> 
>> Why not exactly not?
> 
> Firstly, a fundamental architectural change of how we would recommend 
> application transport to work is not appropriate for this document.

There is no architectural change in using UDP for tunnels. There’s a section in 
RFC 8085 on this if you want a citation.

> ...
>> Frag and reassembly outside of an app can be, in some cases, more efficient 
>> - even with additional layers of headers.
> 
> Yes, in _some_ cases. Try to introduce 1% of packet drop and that number of 
> cases likely drop to 0.

(speaking of hand waving…)

> The large scale deployments of this kind of thing is for example TSO/GSO.

Oh, now we’re off into implementation mechanisms (not standards) that don’t 
follow existing standards either in many cases.

> As a way to bypass bottlenecks in packet processing in the kernel.
> But there segmentation is done at the transport layer, which will not suffer 
> from the issues of a single packet drop in a 40 fragment chain.
> (64K packet / 1500).

Fragmentation is fragmentation. If you send 64K messages and lose one fragment 
- at any layer of a protocol - you lose the message. Unless you send those 
fragments over a reliable channel that retransmits (e.g., TCP) anyway. 

> 
>>> If this paragraph has to be there it would be more accepting to have it in 
>>> the "Legacy protocols" parapgraph above.
>> 
>> It’s unnecessarily limiting to mention it only there.
> 
> The whole purpose of this document is to limit use of network layer 
> fragmentation.

NO IT IS NOT.

It is to reduce the impact of the FAILURE of network layer fragmentation - 
which 

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

[Joe Touch]

> 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
> reliably."
> That seems like hand-waving to me. Suggest deleting.
 
 Fragmentation success or failure is directly testable. Any feedback 
 mechanism will work and specific ones are mentioned elsewhere (PLPMTUD).
 
 This differs from ICMP black-holing in path MTU detection.
>>> 
>>> Can you please point me to where in the PLPMTUD document testing for IP 
>>> fragmentation is described?
>> 
>> Any feedback mechanism will detect when fragmentation - or anything else - 
>> prevents delivery.
> 
> Any pointer to such a mechanism in any IETF protocol?
> Would be interesting to get transport/application perspective on this.
> But unless there is a reference I would claim this is hand-waving.

As I said, PLPMTUD. It doesn’t have to detect if there’s a layer of 
fragmentation it can’t detect; it figures out for itself that a given MTU 
doesn’t succeed and sends a smaller MTU.

> 
> [...]
> 
>> If you fragment and put the result inside GRE or UDP, the impact of the 
>> fragment (interfering with flow-based multi path routing, nat traversal, 
>> etc) is overcome.
> 
> Sure, but that only applies to tunnels that go end to end.

It applies to tunnels that traverse wherever fragmentation is both needed and 
doesn’t work other ways.

Speaking of deployed mechanisms, it’s also how IPsec tunnels over UDP already 
work and are widely deployed.

> ...This document should not recommend IP in UDP in IP encapsulation to 
> achieve end to end IP fragmentation for new applications.

Why not exactly not?

Frag and reassembly outside of an app can be, in some cases, more efficient - 
even with additional layers of headers.

> If this paragraph has to be there it would be more accepting to have it in 
> the "Legacy protocols" parapgraph above.

It’s unnecessarily limiting to mention it only there.

Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 include mechanisms to detect that IP fragmentation isn't 
>>> working
>>> reliably."
>>> That seems like hand-waving to me. Suggest deleting.
>> 
>> Fragmentation success or failure is directly testable. Any feedback 
>> mechanism will work and specific ones are mentioned elsewhere (PLPMTUD).
>> 
>> This differs from ICMP black-holing in path MTU detection.
> 
> Can you please point me to where in the PLPMTUD document testing for IP 
> fragmentation is described?

Any feedback mechanism will detect when fragmentation - or anything else - 
prevents delivery.

> I thought PLPMTUD found the largest unfragmented size of a datagram.

It does - by trying larger sizes and telling the next layer down not to 
fragment. But if there are layers below that either ignore that or aren’t 
directly controlled that do fragment and those fragments don’t get through, it 
will back off.

> 
>>> 2) Paragraph 4:
>>> "The risks of IP fragmentation can also be mitigated
>>> through the use of encapsulation, e.g., by transmitting IP fragments
>>> as payloads."
>>> 
>>> This seems like proposing new unspecified solutions with it's own set
>>> of considerations.
>> 
>> Specific widely-deployed methods are mentioned elsewhere in the doc, 
>> including GRE and UDP.
> 
> Sorry, I couldn't find those either.
> Inner fragmentation, firstly is only applicable to IPv4. And only applicable 
> to tunnels.
> And both those specs go to great length in avoiding fragmentation.

If you fragment and put the result inside GRE or UDP, the impact of the 
fragment (interfering with flow-based multi path routing, nat traversal, etc) 
is overcome.

> 
>>> IP fragmentation is a general solution to all hosts,
>>> encapsulation is certainly not in every host,
>> 
>> Actually, it is - unless you’re claiming hosts don’t support UDP.
> 
> Sorry, I don't understand what you mean.
> Are you saying that a new UDP applications should support the following stack:
> 
> IPv6 + UDP + IPv6 + FH + UDP + Applcation data

Yes - if they need FH and can’t do it any other way.

> So to be able to hide IP fragments from the network?

Yes - and again, this already happens for things like IPsec tunnels over UDP.

> While still having to do the full PLPMTUD to function correctly?

No; those would be used in different contexts. PLPMTUD is intended to avoid 
fragmentation but was given above as one of many examples of ways to determine 
when fragmentation caused a problem. E.g. (not that anyone needs to do this, 
but it’s reasonable):

- test using PLPMTUD
- if that fails, the app can decide what to do next
a) use a smaller MTU
b) fragment and encapsulate

Others have pointed out that there are measurements that indicate that (b) can 
be more efficient; regardless, it’s a choice.

> 
>>> and has different
>>> properties with regards to NAT traversal etc.
>> 
>> If by “different” you mean “much more likely to succeed”, agreed.
> 
> I need to see numbers of that. But regardless I don't see the relevance to 
> this document.

It’s the defining reason that IPsec over UDP was developed and is widely 
deployed. Just look at RFCs or the IANA list of assigned ports for how many 
protocols are “over UDP” simply to traverse NATs.

> 
>>> vAlso if encapsulation
>>> was the answer, other segmentation / reassembly that were tunnel
>>> specific could be developed.
>> 
>> It is and is widely used - IPsec tunnels over UDP, e.g.
> 
> That's a encapsulated solution to start with.

IPsec wasn’t encapsulated. Adding encapsulation is the way it traverses tunnels.

> 
>>> Regardless this also amounts of hand-waving
>>> and doesn't seem to offer any advice that can be heeded now.
>>> And of course encapsulation can also exacerbate the problem
>>> by increasing packet size.
>> 
>> Yes, it makes the fragments smaller, which may be additional 
>> effort/performance impact, but it completely hides its impact on successful 
>> forwarding.
> 
> You may be making a point. I'm afraid I don't get it.

You keep saying this doesn’t help but it’s widely deployed and used already. 

joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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."
>   That seems like hand-waving to me. Suggest deleting.

Fragmentation success or failure is directly testable. Any feedback mechanism 
will work and specific ones are mentioned elsewhere (PLPMTUD).

This differs from ICMP black-holing in path MTU detection.

> 
> 2) Paragraph 4:
>   "The risks of IP fragmentation can also be mitigated
>   through the use of encapsulation, e.g., by transmitting IP fragments
>   as payloads."
> 
>   This seems like proposing new unspecified solutions with it's own set
>   of considerations.

Specific widely-deployed methods are mentioned elsewhere in the doc, including 
GRE and UDP.

>   IP fragmentation is a general solution to all hosts,
>   encapsulation is certainly not in every host,

Actually, it is - unless you’re claiming hosts don’t support UDP.

> and has different
>   properties with regards to NAT traversal etc.

If by “different” you mean “much more likely to succeed”, agreed.

> vAlso if encapsulation
>   was the answer, other segmentation / reassembly that were tunnel
>   specific could be developed.

It is and is widely used - IPsec tunnels over UDP, e.g.

>  Regardless this also amounts of hand-waving
>   and doesn't seem to offer any advice that can be heeded now.
>   And of course encapsulation can also exacerbate the problem
>   by increasing packet size.

Yes, it makes the fragments smaller, which may be additional effort/performance 
impact, but it completely hides its impact on successful forwarding.

---
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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:
> Bob,
>
> I think that this is a close to consensus as we are going to get.
>
>Ron
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Bob Hinden  
> Sent: Thursday, September 5, 2019 2:29 PM
> To: int-area@ietf.org
> Cc: Bob Hinden ; Alissa Cooper ; 
> IESG ; Joel Halpern ; 
> draft-ietf-intarea-frag-frag...@ietf.org; intarea-cha...@ietf.org; Suresh 
> Krishnan 
> Subject: Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
>
> Hi,
>
> Based on the discussion, I would like to propose to see if this will resolve 
> the issues raised.   It attempts to cover the issues raised.
>
> The full section 6.1 is included below, but only the last sentence in the 
> second paragraph changed.
>
> Please review and comment.
>
> Thanks,
> Bob
>
>
>
> 6.1.  For Application and Protocol Developers
>
>Developers SHOULD NOT develop new protocols or applications that rely
>on IP fragmentation.  When a new protocol or application is deployed
>in an environment that does not fully support IP fragmentation, it
>SHOULD operate correctly, either in its default configuration or in a
>specified alternative configuration.
>
>While there may be controlled environments where IP fragmentation
>works reliably, this is a deployment issue and can not be known to
>someone developing a new protocol or application.  It is not
>recommended that new protocols or applications be developed that rely
>on IP fragmentation.  Protocols and applications that rely on IP
>fragmentation will work less reliably on the Internet unless they
>also include mechanisms to detect that IP fragmentation isn't working
>reliably.
>
>Legacy protocols that depend upon IP fragmentation SHOULD be updated
>to break that dependency.  However, in some cases, there may be no
>viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
>in-IP encapsulation).  In these cases, the protocol will continue to
>rely on IP fragmentation but should only be used in environments
>where IP fragmentation is known to be supported.
>
>Protocols may be able to avoid IP fragmentation by using a
>sufficiently small MTU (e.g.  The protocol minimum link MTU),
>disabling IP fragmentation, and ensuring that the transport protocol
>in use adapts its segment size to the MTU.  Other protocols may
>deploy a sufficiently reliable PMTU discovery mechanism
>(e.g.,PLMPTUD).
>
>UDP applications SHOULD abide by the recommendations stated in
>Section 3.2 of [RFC8085].
>
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 years that they shouldn't
> use in their new applications they want to deploy seems trite to me.

It's worth noting that apps don't always have any control over whether
they use such tunnels or not, or whether they can override the OS's keen
desire in using the largest MTUs possible (e.g., in TCP).

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 by the IESG and add an appendix recording 
> contrary opinions and identifying them as such
> - Progress it as it was approved by the IESG, deleting controversial sections 
> and remaining silent on these issues
> 
> Does anybody see any other options?

You seem to be overlooking:

- progress it as it was approved by the WG and IETF LC and add an appendix 
recording contrary IESG opinions and identifying them as such
- progress it based on the text I suggested as was agreed by consensus in this 
discussion and add an appendix recording contrary IESG opinions and identifying 
them as such

This isn’t an IESG opinion. They get to write those themselves.

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

IMO, it belongs back with a forward reference to the detail. 

To do otherwise buries at least part of the lead here - as you note in
another response - to not mistake this document for a step towards
deprecation. 

Joe 

On 2019-09-04 10:57, Fred Baker wrote:

> Sent using a machine that autocorrects in interesting ways...
> 
> It was taken out in response to Warren Kumari's comment that it was out of 
> place and already covered in a section later in the document. If it is added 
> back in, it probably belongs in that section, not the introduction.
> 
> On Sep 3, 2019, at 5:33 PM, Templin (US), Fred L  
> wrote:
> 
> Why was this section taken out:
> 
> 1.1.  IP-in-IP Tunnels 
> 
> This document acknowledges that in some cases, packets must be 
> fragmented within IP-in-IP tunnels [I-D.ietf-intarea-tunnels]. 
> Therefore, this document makes no additional recommendations 
> regarding IP-in-IP tunnels. 
> Tunnels always inflate the size of packets to the point that they may exceed
> the path MTU even if the original packet is no larger than the path MTU. And,
> for IPv6 the only guarantee is 1280. Therefore, 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 Behalf Of Joe Touch
> Sent: Tuesday, September 03, 2019 7:06 AM
> To: Alissa Cooper 
> Cc: Joel Halpern ; 
> draft-ietf-intarea-frag-frag...@ietf.org; int-area@ietf.org; The IESG 
> ;
> intarea-cha...@ietf.org
> Subject: 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" without citation
> d) most importantly:
> 
> REMOVES a key recommendation that we MAY use frag where it works
> 
> Asserts the false claim that IP fragmentation "will fail" in the Internet,
> despite citing evidence that the *majority of the time* it does work
> e.g., for IPv6, sec 3.9
> 
> What happened? Why is a change this substantial not reflecting the *list 
> consensus*?
> 
> Joe
> 
> On Sep 3, 2019, at 5:59 AM, Alissa Cooper via Datatracker  
> wrote: 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-intarea-frag-fragile-16: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
> 
> --
> COMMENT:
> --
> 
> Thanks for addressing my DISCUSS.
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 appropriate. But this was NOT a matter of one person 
> commenting and unrelated edits happening.
> 
> For the record, I agree that fragmentation will in fact be used by 
> applications and transports that are using it now, unless and until they are 
> changed. Expecting otherwise is a fool's errand. Hence, while there are known 
> problems with it, fragmentation and reassembly MAY be used. I don't think 
> anyone is disputing that.

And yet the text that says exactly that has been removed and replaced
with text that says exactly the opposite (that it will fail). 

So whose consensus is this currently representing? 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 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 the time (failing 37% for IPv6 DNS resolvers is succeeding 
>> 63%). This is not the same as ICMP-based MTU discovery. Users absolutely can 
>> test and know this.
>> 
>> I repeat my previous suggestion with caps for emphasis- that, LIKE ALL 
>> PROTOCOLS AND FEATURES IN THE INTERNET, IP fragmentation is not guaranteed 
>> to work on any given path and should be confirmed before being relied upon.
> 
> The relevant text in -16 is:
> 
> 6.1.  For Application and Protocol Developers
> 
> Developers SHOULD NOT develop new protocols or applications that rely
> on IP fragmentation.  When a new protocol or application is deployed
> in an environment that does not fully support IP fragmentation, it
> SHOULD operate correctly, either in its default configuration or in a
> specified alternative configuration.
> 
> While there may be controlled environments where IP fragmentation
> works reliably, this is a deployment issue and can not be known to
> someone developing a new protocol or application.  It is not
> recommended that new protocols or applications be developed that rely
> on IP fragmentation.  Protocols and applications that rely on IP
> fragmentation will fail to work on the Internet.
> 
> The text in the first paragraph is unchanged in this version of the draft and 
> has been there for awhile.  The recommendation is still SHOULD NOT.   This 
> does allow other usage if there is a good reason to do so.
> 
> The new second paragraph (written to resolve the DISCUSS comment) attempts to 
> discuss the the controlled environment case. It clearly states it is a 
> recommendation (along the lines of the SHOULD NOT) in the first paragraph and 
> explains why.

It drops the idea that this is allowed - and is factually incorrect. 

First, this absolutely can be known to deployers. This is not like
silent ICMP too-big drops where the cause of the drop cannot be known. 

Second, it's already widely deployed to deal with IP-IP tunnels. 

> Note, personally I think, citing your case of failing 37% of the time, is 
> consistent with "will fail to work on the Internet".

Failing 37% of the endpoints is not the same as failing 37% of the time.
And no, neither one is consistent with "will fail on the Internet". If
you think 37% = will fail, then I'll open a personal casino for you with
those odds for you to win... 

> Also, isn't this the reason why this draft exists, that is fragmentation is 
> fragile.

There are differences of opinion even within the WG as to why this draft
exists. I would believe the authors believe as you state, but others of
us believe that "implementations are buggy" is more the take-home. The
WG and IETF last calls tried to strike a balance that this change
undoes. 

This is not respecting the view of the WG or IETF. 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 review has a problem with a given part of the doc, it's fair
game to open up other parts to address the change. There are no truly
local changes. 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 simply:
> 
> 5.3.  Packet-in-Packet Encapsulations
> 
> This document acknowledges that in some cases, packets must be
> fragmented within IP-in-IP tunnels.  Therefore, this document makes no
> additional recommendations regarding IP-in-IP tunnels.
> See [I-D.ietf-intarea-tunnels] for further discussion.

There was a reason this text was included up front - despite the
implications of this draft, IP-IP tunnels are not going anywhere anytime
soon. IPsec tunnel mode has not been deprecated. 

To Bob's other point, this was approved by the WG and the IETF last call
as up front. 

Why are we changing it now? 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

Remember that IPsec uses IP in IP too. Shim layers won’t help it.  

Joe

> On Sep 3, 2019, at 2:10 PM, Templin (US), Fred L  
> wrote:
> 
> Bob,
> 
>> -Original Message-
>> From: Bob Hinden [mailto:bob.hin...@gmail.com]
>> Sent: Tuesday, September 03, 2019 1:57 PM
>> To: Tom Herbert 
>> Cc: Bob Hinden ; Templin (US), Fred L 
>> ; int-area@ietf.org; IESG
>> ; Joel Halpern ; 
>> draft-ietf-intarea-frag-frag...@ietf.org; intarea-cha...@ietf.org
>> Subject: Re: [Int-area] Alissa Cooper's No Objection on 
>> draft-ietf-intarea-frag-fragile-16: (with COMMENT)
>> 
>> Tom,
>> 
>>> On Sep 3, 2019, at 1:33 PM, Tom Herbert  wrote:
>>> 
>>> Bob,
>>> 
>>> I agree with Fred. Note, the very first line of the introduction:
>>> 
>>> "Operational experience [Kent] [Huston] [RFC7872] reveals that IP
>>> fragmentation introduces fragility to Internet communication”.
>> 
>> Yes, that text in in the first paragraph of the Introduction
>>> 
>>> This attempts to frame fragmentation as being generally fragile with
>>> supporting references. However, there was much discussion on the list
>>> about operational experience that demonstrates fragmentation is not
>>> fragile. In particular, we know that fragmentation with tunnels is
>>> productively deployed and has been for quite some time. So that is the
>>> counter argument to the general statement that fragmentation is
>>> fragile. With the text about tunneling included in the introduction I
>>> believe that was sufficient balance of the arguments, but without the
>>> text the reader could be led to believe that fragmentation is fragile
>>> for everyone all the time which is simply not true and would be
>>> misleading.
>> 
>> Yes, but we are discussing some text from the Introduction that to my read 
>> didn’t say anything useful so I removed it.  The substantive
>> text about tunneling in in Section 3.5.  The Introduction, is just the 
>> introduction.  The text was:
>> 
>>   This document acknowledges that in some cases, packets must be
>>   fragmented within IP-in-IP tunnels [I-D.ietf-intarea-tunnels].
>>   Therefore, this document makes no additional recommendations
>>   regarding IP-in-IP tunnels.
> 
> Yes - good text that should be retained.
> 
>> Why is that more useful than what is in 3.5? If it’s not making a 
>> recommendation, why call this out in the introduction.  There are lot of
>> other things it doesn’t make recommendations about that aren’t in the 
>> Introduction either.
> 
> Because it sets a more appropriate tone and lets the reader know from the 
> onset that
> fragmentation and encapsulation go hand in hand. And tunnel fragmentation 
> avoids the
> issues raised by others in this thread.
> 
> Thanks - Fred
> 
>> Bob
>> 
>>> 
>>> Speaking of balance, the introduction also mentions that:
>>> 
>>> "this document recommends that upper-layer protocols address the
>>> problem of fragmentation at their layer"
>>> 
>>> But the "problem" of fragmentation is in intermediate devices that
>>> don't properly handle it as the draft highlights. So it seems like
>>> part 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 as document editor.  This to my understanding has been through 
>> w.g. last call and now IESG review.
>>> 
>>> Tom
>>> 
>>> 
>>> 
>>> Tom
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Tue, Sep 3, 2019 at 1:01 PM Bob Hinden  wrote:
>>>> 
>>>> Fred,
>>>> 
>>>>> On Sep 3, 2019, at 12:45 PM, Templin (US), Fred L 
>>>>>  wrote:
>>>>> 
>>>>> Bob,
>>>>> 
>>>>>> -Original Message-
>>>>>> From: Bob Hinden [mailto:bob.hin...@gmail.com]
>>>>>> Sent: Tuesday, September 03, 2019 9:10 AM
>>>>>> To: Templin (US), Fred L 
>>>>>> Cc: Bob Hinden ; Joe Touch ; 
>>>>>> Alissa Cooper ; Joel
>> Halpern
>>>>>> ; draft-ietf-intarea-frag-frag...@ietf.org; 
>>>>>> int-area@ietf.org; IESG ; intarea-
>>>>>> cha...@ietf.org
>>>>

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

[Joe Touch]

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” without citation
d) most importantly:

REMOVES a key recommendation that we MAY use frag where it works

Asserts the false claim that IP fragmentation “will fail” in the 
Internet,
despite citing evidence that the *majority of the time* it does work
e.g., for IPv6, sec 3.9

What happened? Why is a change this substantial not reflecting the *list 
consensus*?

Joe

> On Sep 3, 2019, at 5:59 AM, Alissa Cooper via Datatracker  
> wrote:
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-intarea-frag-fragile-16: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for addressing my DISCUSS.
> 
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 the time (failing 37% for IPv6 DNS resolvers is
succeeding 63%). This is not the same as ICMP-based MTU discovery. Users
absolutely can test and know this. 

I repeat my previous suggestion with caps for emphasis- that, LIKE ALL
PROTOCOLS AND FEATURES IN THE INTERNET, IP fragmentation is not
guaranteed to work on any given path and should be confirmed before
being relied upon. 

Joe

On 2019-08-30 14:31, internet-dra...@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Internet Area Working Group WG of the IETF.
> 
> Title   : IP Fragmentation Considered Fragile
> Authors : Ron Bonica
> Fred Baker
> Geoff Huston
> Robert M. Hinden
> Ole Troan
> Fernando Gont
> Filename: draft-ietf-intarea-frag-fragile-16.txt
> Pages   : 28
> Date: 2019-08-30
> 
> Abstract:
> This document describes IP fragmentation and explains how it
> introduces fragility to Internet communication.
> 
> This document also proposes alternatives to IP fragmentation and
> provides recommendations for developers and network operators.
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-16
> https://datatracker.ietf.org/doc/html/draft-ietf-intarea-frag-fragile-16
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-frag-fragile-16
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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?

Unless we ever get serious about protocol compliance, it’s a huge waste of time 
to focus on levels of non-compliance.

Regardless, what’s wrong or inaccurate about my suggested revision?

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 
conformance mechanism. Like any other protocol feature, IP fragmentation is 
useful only when it actually works - both by successfully traversing routers 
and other in-network devices and when it is correctly supported by endpoints. 
As a consequence, like any other protocol feature, IP fragmentation MAY be used 
by new protocols that validate its successful traversal and provide an 
alternate as a backup.”

(and yes, if we’re going to try to imply that frag is limited, it really should 
be clear that this is *no different than any other protocol feature* in the 
Internet)

Joe

> On Aug 15, 2019, at 6:59 AM, Ron Bonica 
>  wrote:
> 
> Folks,
> 
> Has anyone proposed text that:
> 
> a) satisfies Alissa's request
> b) satisfies the WG
> 
> If not, do we believe that such text could possibly exist?
> 
>  Ron
> 
> 
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: Brian E Carpenter  
> Sent: Tuesday, August 6, 2019 8:55 PM
> To: Alissa Cooper ; Tom Herbert 
> Cc: Joel Halpern ; 
> draft-ietf-intarea-frag-frag...@ietf.org; int-area ; IESG 
> ; intarea-chairs 
> Subject: Re: [Int-area] Alissa Cooper's Discuss on 
> draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)
> 
> On 07-Aug-19 12:11, Alissa Cooper wrote:
>> Hi Tom,
>> 
>>> On Aug 6, 2019, at 5:41 PM, Tom Herbert  wrote:
>>> 
>>> On Tue, Aug 6, 2019 at 1:30 PM Alissa Cooper via Datatracker 
>>>  wrote:
 
 Alissa Cooper has entered the following ballot position for
 draft-ietf-intarea-frag-fragile-15: Discuss
 
 When responding, please keep the subject line intact and reply to 
 all email addresses included in the To and CC lines. (Feel free to 
 cut this introductory paragraph, however.)
 
 
 Please refer to 
 https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ie
 sg_statement_discuss-2Dcriteria.html=DwIFaQ=HAkYuh63rsuhr6Scbfh0
 UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP
 8=IUZsPOprgYi_5nBSPGeqNCLb8LwDMKCxRNeEBfcUZ5c=c7tAk-Lfr6pcQSMn1x
 1tdfjkQsL8F_NryIiq3caZ26k= for more information about IESG DISCUSS 
 and COMMENT positions.
 
 
 The document, along with other ballot positions, can be found here:
 https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet
 f.org_doc_draft-2Dietf-2Dintarea-2Dfrag-2Dfragile_=DwIFaQ=HAkYuh
 63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF
 2EfpHcAwrDThKP8=IUZsPOprgYi_5nBSPGeqNCLb8LwDMKCxRNeEBfcUZ5c=lb6u
 0SVhJIFnTV7TdqeLiDBfadRxJkAxNEDqOvFqhyQ=
 
 
 
 
 --
 DISCUSS:
 
 --
 
 Thanks for writing this document.
 
 Section 6.1 says:
 
 "Developers MAY develop new protocols or applications that rely on IP
  fragmentation if the protocol or application is to be run only in
  environments where IP fragmentation is known to be supported."
 
 I'm wondering if there should be a bit more nuance here to make the 
 recommendation clearer. Do we think there is a case where an 
 application protocol developed in the IETF will be known to only run 
 in environments where fragmentation is supported? If we don't think 
 developing such a protocol would be in scope for the IETF, then I'm 
 wondering if that case should be called out explicitly with a stronger 
 normative requirement.
 
>>> Alissa,
>>> 
>>> Are you distinguishing between protocol development and application 
>>> development?
>> 
>> I’m specifically wondering about application protocols (as distinct from 
>> other protocols) developed in the IETF (as distinct from developed 
>> elsewhere). Sometimes we use BCPs to guide future work in the IETF 
>> specifically, and it seemed to me that in that specific slice — 
>> IETF-developed application protocols — we may be able to make a stronger 
>> recommendation since we can’t be sure of the environment in which any given 
>> application protocol would be deployed (I think, but would be open to 
>> arguments otherwise).
> 
> fwiw, I agree with what I think Alissa is saying. Unless we actually 
> *implement* a mechanism to define and support limited domains 
> (draft-carpenter-limited-domains) protocol designers cannot safely make 
> assumptions such as "fragmentation works".
> 
> Maybe this paragraph needs to be more of a health warning than a somewhat 
> dubious RFC2119 statement. At least, "should not ... unless" might be a 
> better formulation than "MAY ... if".
> 
>   

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

[Joe Touch]

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 devices that are broken, it’s 
equally worth noting in the same breath that these are broken behaviors. 

#4 - a middlebox is any device that relays IP packets but violates RFC1812 by 
modifying parts of the packet beyond the IP header hop count, checksum (IPv4), 
and certain IP options. It is, almost by definition, a bug “in the flesh”.

Joe

> On Aug 7, 2019, at 2:58 PM, Warren Kumari via Datatracker  
> wrote:
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-intarea-frag-fragile-15: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
> 
> 
> 
> --
> COMMENT:
> --
> 
> It's very seldom that I ballot Yes on a document for which I'm not the
> Responsible AD, but this is important enough that I'm doing so; unfortunately
> there are are some bits which make me uncomfortable though, and so I spent a
> while in the unusual situation of trying to decide between DISCUSS and YES -
> after looking at the author list and responsible AD I'm sure that my comments
> will be considered, and so I'm balloting Yes.
> 
> 1: "Legacy protocols that depend upon IP fragmentation SHOULD be updated to
> remove that dependency." I really don't like the  SHOULD here -- while I fully
> agree that legacy protocols should be update, the RFC2119 usage feels weird -
> it's unclear exactly who it is aimed at (everyone? the people who wrote the
> legacy protocols? some mythical cleanup author?)
> 
> 2: I'm unclear why IP-in-IP tunnels are called out at the top / in the
> Introduction. There is a whole section (Packet-in-Packet Encapsulations) where
> I think it would go better -- I see no harm in having people have to read down
> to there to note this.
> 
> 3: "NOTE 2: A non-fragmentable packet can be fragmented at its source. 
> However,
> it cannot be fragmented by a downstream node.  An IPv4 packet whose DF-bit is
> set to 0 is fragmentable.  An IPv4 packet whose DF-bit is set to 1 is
> non-fragmentable.  All IPv6 packets are also non-fragmentable." I have a few
> issues with this: 3.1: I'm not really sure a non-fragmentable packet can be
> fragmented at its source -- the packet *can* be fragmented but I'd say that
> that is before it has become non-fragmentable. It's entirely possible that I'm
> missing something obvious here, but a skim of 791 didn't show me what 3.2:
> This may be a corner case, but some tunneling gear seems happy to ignore the 
> DF
> bit when it is doing reassembly on the far side of the tunnel -- the logic
> seems to be that as long as what goes into the tunnel matches what comes out 
> it
> doesn't matter what actually happens *inside* the tunnel. 3.3: Related  to 
> this
> - most tunneling gear (and many firewalls) allow you to clear the DF bit in
> packets -- for example, cisco has the 'crypto ipsec df-bit clear' command,
> Junos allows you to do 'services ipsec-vpn rule myvpn term stomp_on_df then
> clear-dont-fragment-bit;', iptables lets you 'iptables -t mangle -A 
> POSTROUTING
> -j DF --clear' 3.2 and 3.3 are common enough that I think that they deserve
> mention.
> 
> 4: What do you mean by middle box in section 6.3?
> Yes, I know what is commonly called a middlebox, but I don't know of a good
> reference -- as an example, I've got some honkin' big routers which do
> stateless firewall filtering -- these are covered by 3.7, but are they also
> middleboxes, and if not, why not?! (Note, my personal belief is that they
> aren't, but I cannot really point to why, other than "I know a middlebox when 
> I
> see one". There is a discussion on some of this in "Why Operators Filter
> Fragments and What It Implies" (draft-taylor-v6ops-fragdrop-02), but this also
> uses the term middlebox without defining it.
> 
> Nits:
> A: Whlie -- While
> 
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 
>> anything.
> 
> What I meant is that, whether one likes it or not, at the point
> something does not work (for some meaningful level of failure rate), you
> cannot rely on it anymore. (that wrt the "deprecated" (in a colloquial
> way) bit).
> 
> Regarding security, there are times in which things don't work because
> vendors did such a poor job that supporting a given feature opens your
> networks or devices to attack. Particularly when a feature is not widely
> employed (if at all), it's not surprising that ops people resort to
> blocking the feature.
> 
> Not that I necessarily like it, but that's what reality seems to indicate.

Sometimes they indicate bugs — often that we ought to encourage be fixed. 

Otherwise, as I’ve said before and again above, we end up with the least of 
everything.

In this case, warning people that things might not work isn’t the same as 
“should avoid” or “don’t use”. It could be as simple as “check before relying 
on”, but let’s face it - the Internet is *best effort* throughout anyway, so 
even needing to say that seems redundant.

To the IESG: wordsmithing this document is a bad idea unless it comes with a 
substantial revision explaining the impact of stronger warnings AND is taken 
back to the WG for consensus.

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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.
>> 
>> 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.
> 
> IN a way, it's the operational reality that has deprecated Fragmention
> (and essentially IPv6 EHs, as per RFC7872).
> 
> That is: can you reliably use them? --Not at all... expect when you run
> the network yourself.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 would think the text just above the paragraph Alissa quoted would 
> already cover what you ask for.  It begins:
>Developers SHOULD NOT develop new protocols or applications that
>rely on IP fragmentation.
> 
> Yours,
> Joel
> 
> On 8/6/2019 8:55 PM, Brian E Carpenter wrote:
>> On 07-Aug-19 12:11, Alissa Cooper wrote:
>>> Hi Tom,
>>> 
 On Aug 6, 2019, at 5:41 PM, Tom Herbert  wrote:
 
 On Tue, Aug 6, 2019 at 1:30 PM Alissa Cooper via Datatracker
  wrote:
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-intarea-frag-fragile-15: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Thanks for writing this document.
> 
> Section 6.1 says:
> 
> "Developers MAY develop new protocols or applications that rely on IP
>   fragmentation if the protocol or application is to be run only in
>   environments where IP fragmentation is known to be supported."
> 
> I'm wondering if there should be a bit more nuance here to make the
> recommendation clearer. Do we think there is a case where an application
> protocol developed in the IETF will be known to only run in environments 
> where
> fragmentation is supported? If we don't think developing such a protocol 
> would
> be in scope for the IETF, then I'm wondering if that case should be 
> called out
> explicitly with a stronger normative requirement.
> 
 Alissa,
 
 Are you distinguishing between protocol development and application
 development?
>>> 
>>> I’m specifically wondering about application protocols (as distinct from 
>>> other protocols) developed in the IETF (as distinct from developed 
>>> elsewhere). Sometimes we use BCPs to guide future work in the IETF 
>>> specifically, and it seemed to me that in that specific slice — 
>>> IETF-developed application protocols — we may be able to make a stronger 
>>> recommendation since we can’t be sure of the environment in which any given 
>>> application protocol would be deployed (I think, but would be open to 
>>> arguments otherwise).
>> fwiw, I agree with what I think Alissa is saying. Unless we actually 
>> *implement* a mechanism to define and support limited domains 
>> (draft-carpenter-limited-domains) protocol designers cannot safely make 
>> assumptions such as "fragmentation works".
>> Maybe this paragraph needs to be more of a health warning than a somewhat 
>> dubious RFC2119 statement. At least, "should not ... unless" might be a 
>> better formulation than "MAY ... if".
>>Brian
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

Hi, Bob,

This seems like a useful approach (though I’ll leave it to you and others to 
track the exact details).

Joe

> On Jul 8, 2019, at 5:27 AM, Bob Briscoe  wrote:
> 
> Joe,
> 
> Following up my email to you in May quoted further down, you made me realize 
> that RFC6040 did not address what to do with ECN during fragmentation and 
> reassembly. So I've added the following to my local copy of 
> draft-ietf-tsvwg-rfc6040-update-shim (to be posted later today), which 
> recently went through TSVWG last call, and will imminently be last called on 
> various int-area lists, I believe.
> 
> These are quite significant updates to outer fragment processing at the 
> tunnel egress. But, given something has to be said, I can't think of a better 
> way (see the original quoted email about why the logical OR of the ECN 
> codepoints as defined in RFC3168 is no longer sufficient - and it's no 
> simpler anyway).
> 
> 5.  ECN Propagation and Fragmentation/Reassembly
> 
>The following requirements update RFC6040, which omitted handling of
>the ECN field during fragmentation or reassembly.  These changes
>might alter how many ECN-marked packets are propagated by a tunnel
>that fragments packets, but this would not raise any backward
>compatibility issues:
> 
>If a tunnel ingress fragments a packet, it MUST set the outer ECN
>field of all the fragments to the same value as it would have set if
>it had not fragmented the packet.
> 
>As a tunnel egress reassembles sets of outer fragments
>[I-D.ietf-intarea-tunnels] into packets, it SHOULD propagate CE
>markings on the basis that a congestion indication on a packet
>applies to all the octets in the packet.  On average, a tunnel egress
>SHOULD approximately preserve the number of CE-marked and ECT(1)-
>marked octets arriving and leaving (counting the size of inner
>headers, but not encapsulating headers that are being stripped).
>This process proceeds irrespective of the addresses on the inner
>headers.
> 
>Even if only enough incoming CE-marked octets have arrived for part
>of the departing packet, the next departing packet SHOULD be
>immediately CE-marked.  This ensures that CE-markings are propagated
>immediately, rather than held back waiting for more incoming CE-
>marked octets.  Once there are no outstanding CE-marked octets, if
>only enough incoming ECT(1)-marked octets have arrived for part of
>the departing packet, the next departing packet SHOULD be immediately
>marked ECT(1).
> 
>For instance, an algorithm for marking departing packets could
>maintain a pair of counters, the first representing the balance of
>arriving CE-marked octets minus departing CE-marked octets and the
>second representing a similar balance of ECT(1)-marked octets.  The
>algorithm:
> 
>o  adds the size of every CE-marked or ECT(1)-marked packet that
>   arrives to the appropriate counter;
> 
>o  if the CE counter is positive, it CE-marks the next packet to
>   depart and subtracts its size from the CE counter;
> 
>o  if the CE counter is negative but the ECT(1) counter is positive,
>   it marks the next packet to depart as ECT(1) and subtracts its
>   size from the ECT((1) counter;
> 
>o  (the previous two steps will often leave a negative remainder in
>   the counters, which is deliberate);
> 
>o  if neither counter is positive, it marks the next packet to depart
>   as ECT(0);
> 
>o  until all the fragments of a packet have arrived, it does not
>   commit any updates to the counters so that, if reassembly fails
>   and the partly reassembled packet has to be discarded, none of the
>   discarded fragments will have updated any of the counters.
> 
>During reassembly of outer fragments [I-D.ietf-intarea-tunnels], if
>the ECN fields of the outer headers being reassembled into a single
>packet consist of a mixture of Not-ECT and other ECN codepoints, the
>packet MUST be discarded.
> 
>A tunnel end-point that claims to support the present specification
>MUST NOT use an approach that results in a significantly different
>ECN-marking outcome 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 22:14, Bob Briscoe wrote:
>> Joe,
>> 
>> Sorry I missed this posting at the time (my mail filters moved both 
>> cross-postings into my int-area box which I check only rarely).
>> 
>>

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

[Joe Touch]

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-tunnels 
(which relates to the above) and its discussion on many of the protocols cited

Joe

> On Apr 26, 2019, at 1:50 PM, Black, David  wrote:
> 
> This may be of interest to INT folks who are interested in tunnels and 
> encapsulations.
>  
> Comments by the WGLC deadline are encouraged, but comments after the deadline 
> are ok, as they’d have to be dealt with anyway at IETF Last Call.
>  
> Thanks, --David
>  
> From: tsvwg mailto:tsvwg-boun...@ietf.org>> On 
> Behalf Of Black, David
> Sent: Wednesday, April 17, 2019 2:51 PM
> To: ts...@ietf.org 
> Subject: [tsvwg] 2nd WGLC on ecn-encap-guidelines and rfc6040-update-shim 
> drafts, closes 6 May 2019
>  
> [EXTERNAL EMAIL] 
> 
> This email announces a 2nd TSVWG Working Group Last Call (WGLC) on two drafts:
>  
> [1] Guidelines for Adding Congestion Notification to Protocols that
>  Encapsulate IP
> draft-ietf-tsvwg-ecn-encap-guidelines-12
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ 
> 
> This draft is intended to become a Best Current Practice RFC
>  
> [2] Propagating Explicit Congestion Notification Across IP Tunnel Headers
>   Separated by a Shim
>  draft-ietf-tsvwg-rfc6040update-shim-08
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ 
> 
> This draft is intended to become a Proposed Standard RFC.
>  
> This WGLC will run through the end of the day on Monday, May 6, 2019.
>  
> Comments should be sent to the ts...@ietf.org  list, 
> although purely
> editorial comments may be sent directly to the author. Please cc: the
> WG chairs at tsvwg-cha...@ietf.org   if you 
> would like the chairs to
> track such editorial comments as part of the WGLC process.
>  
> No IPR disclosures have been submitted directly on either draft
>  
> Thanks,
> David, Gorry and Wes
> (TSVWG Co-Chairs)
>  
> ___
> Int-area mailing list
> Int-area@ietf.org 
> https://www.ietf.org/mailman/listinfo/int-area 
> 
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 questions that I’d 
> like to pass to the WG/editors for consideration.
> 
> Best wishes,
> 
> Gorry
> 
> (I also earlier posted some editorial comments.)
> 
> 
> *** Technical questions:
> 
> In section 4.1.1:
> “Similarly, the DF field of the
> transit packet is not related to that field in the tunnel link packet
> header (presuming both are IPv4) “
> - Why is this not true when IPv4 and IPv6 are used in combination to tunnel 
> one over the other?

Because IPv6 has no DF field. DF on DF matters only when both headers have DF 
;-)

IPv6 is always DF, so there are cases to explain, though.

I can make that more clear.

> ---
> In section4.2.1:
> “The high cost of
> fragmentation and reassembly is why it is useful for applications to
> avoid sending messages too close to the size of the tunnel path MTU
> [Ke95], although there is no signaling mechanism that can achieve
> this (see Section 4.2.3).”
> - This sentence seems like teh cost is just segmentation/reassembly costs. 
> It's more complex we you wish to defend from attack and need to keep state in 
> devices. So the original paper cited is just one part of the whole problem 
> space. This ID seems to help clarify some of these issues: 
> [I-D.ietf-intarea-frag-fragile-09].

As an aside, IMO, that document is a thinly veiled attempt to deprecate 
fragmentation that I continue to have concerns over.

That said, this sentence describes the problem of trying to tune closely to the 
tunnel path MTU; the attack and state issues in frag-fragile aren’t affected by 
whether a 2000B packet is split into 1280 and 720 or 1000 and 1000. It 
basically implies (though it could be more clear) that 1280 and 720 is a bad 
choice because the 1280 could later end up being fragmented into 1200, 80, and 
720 (as a set) vs 1000 and 1000 if then going over a tunnel that needs to 
fragment to support 1280.

This can happen when you do PMTUD one hop at a time or even if you do the 
entire path with PMTUD if path properties change even a little (see below).

> - If you probed with context, as in (D)PLPMTUD you could achieve this signal?

You could but see above - the issue is trying to over-tune, not whether you can 
tune or not.

> Some further context on how to build more robust solutions is in 
> [I-D.ietf-tsvwg-datagram-plpmtud].Using that approach I don’t see why that is 
> the case - maybe my question is because section 4.2.3 is exclusively about 
> PMTUD, and not PLPMTUD?

It wasn’t intended that way - it doesn’t matter how you find out, if you tune 
too close you end up running risks due to path changes, tunnel overhead 
changes, etc. too - even if you do it for the full path (PLPMTUD) vs each hop 
one at a time (PMTUD).

> ---
> In section 4.2.2:
> “Although many of these issues with tunnel fragmentation and MTU
> handling were discussed in [RFC4459]”
> - What is the relationship to the ID on Fragmentation Fragile 
> [I-D.ietf-intarea-frag-fragile-09]?

Well, to start with I’m not trying to deprecate fragmentation — in fact, this 
document is a good reason why that can’t happen...

> - The present document in 5.3.1. states: “Always include frag support for at 
> least two frags; do NOT try to deprecate fragmentation.“, which seems to be 
> slightly incompatible with the other WG document?

Yes, IMO it is if you interpret frag-fragile as deprecating fragmentation (as I 
do, though the authors continue to claim isn’t really true - they’re just 
trying to get fragmentation to not be used, rather than to outlaw it).

> ---
> In section 4.3.2:
> - I think the following is open to misinterpretation and that concerns me, 
> itdoes not seem strong enough::
> “ Tunnels carrying IP traffic (i.e., the focus of this document) need
> not react directly to congestion any more than would any other link
> layer [RFC8085].”
> - This refers to the UDP-Guidelines as BCP, which is OK, but if that is a 
> reference then please more precisely quote the text in that RFC that says:
> “Two factors determine whether a UDP tunnel needs to employ specific
> congestion control mechanisms: first, whether the payload traffic is
> IP-based; and second, whether the tunneling scheme generates UDP
> traffic at a volume that corresponds to the volume of payload traffic
> carried within the tunnel.”
> - Is it posisble to also add a cition the detailed guidance in section 3.1.11 
> of RFC8085?

Yes.

> - It would be good to say [RFC2914] describes the best current practice for 
> congestion control. Would that be OK?

Sure.

> - Please also consider citing [RFC8084] as a way to provide network tunnels 
> and applications when using non-congestion-controlled traffic, to illustrate 
> what can be done to realise some 

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

[Joe Touch]

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 that I am reviewing. I have a number of comments that I’d like to 
> pass to the WG/editors for consideration, I also have a few more technical 
> questions, that I will post later.
> 
> --- My first top-level comment is that I fear a small part of the language in 
> the document could put some readers off because it seems to go-back-in-time 
> to cite early ways of describing networks, which I think could be easily 
> tuned to avoid this and make it much more accessible to younger folk - who 
> probably are a really important audiance (see NiTs below).

I’ll look; it certainly is important to start with Internet terms (gateway, 
datagram, etc.) before jumping into more recent terms.

> --- There are places where IPv4 language is used, and I'd prefer to make sure 
> that IPv6 is regarded as equally in all places (see NiTs).

Agreed,

> --- It would be good to refer to and clarify the recommendations in 
> [I-D.ietf-tsvwg-ecn-encap-guidelines], [I-D.ietf-tsvwg-rfc6040update-shim] 
> and [I-D.ietf-tsvwg-datagram-plpmtud] witin TSVWG, and also IP Fragmentation 
> Considered Fragile [I-D.ietf-intarea-frag-fragile-09].

Certainly - thanks for noting that. The doc has been in development over an 
absurdly long time (due to waxing and waning IETF interest), but I do hope we 
can wrap things up now that there seems to be broader interest.

Further notes below...

> 
> Best wishes,
> 
> Gorry
> 
> —

> "The opening sentence of the Introduction states “The Internet layering 
> architecture is loosely based on the ISO seven
> layer stack, in which data units traverse the stack by being wrapped
> inside data units of the next layer down [Cl88][Zi80]”.
> 
> - While I totally agree with the observation, I wonder about the prudence in 
> starting the Intro with this sentence. For many years Universities (at least 
> where I have been) have taught the ISO model as a formal protocol stack as 
> well as an architectural model. That’s not common anymore, and starting with 
> a historical fact can actually deter “younger” readers.
- this remains the dominant model for teaching (top-down or bottom-up)
- I know of only one teaching approach and textbook that do not use that model 
(and it’s mine and under development ;-)

> - The text could you say something like:
> 
> “The Internet layering architecture follows a layered model, in which data 
> units traverse a stack by being wrapped inside data units of the next layer 
> down [Cl88][Zi80]”.

It’s important to refer to the ISO 7-layer stack because it remains dominant in 
protocol stack descriptions (even the idea of a protocol stack, inaccurate as 
it is, is based thereon).

> 
> - and later, this strikes me as somewhat old-fashioned:
> “ Such descriptions can help explain
> behavior, as when the OSI seven-layer model is used as a teaching
> example [Zi80].”
> 
> - and again:
> “An Internet gateway is an OSI Layer 3 router when it
> transits IP datagrams but it acts as an OSI Layer 2 host as it
> sources or sinks Layer 2 messages on attached links to accomplish
> this transit capability. “

See above.

> - That’s pretty old-fashioned language for a reader in 2019, and definitely 
> not the language that anyone brought up with IPv6 would
> recognise. Since those early days “gateway” has had different interpretations 
> by different readers - and that’s even more so today.

Agreed; I’ll provide a translation table up front and use more modern terms.

> 
> ---
> - Similarly, this seems quaint:
> “There is essentially no difference between a tunnel and
> the conventional layering of the ISO stack (i.e., by this
> definition, Ethernet is can be considered tunnel for IP).”
> - Is it talking about protocol encapsulation? In 2019 do we need to mention 
> the ISO Stack?

We do - the stack is an ISO concept.

Yes, this refers to protocol encapsulation.

Note that this sentence is fundamental to much of the rest of the document - 
i.e., if you get tunneling right, you can’t tell the difference between running 
over a tunnel vs. running over the next protocol layer down.

> ---
> 
> - The multicast discussion is split between two parts fo the intro. The 
> phrases:
> “Tunnels allowed multicast
> packets to transit efficiently between multicast-capable routers over
> paths that did not support native link-layer multicast.”
> ... introduce multicast before the list of protocols, but the discussion of 
> multicast continues after more current examples in
> “The first attempt to use large-scale tunnels was to transit multicast
> traffic across the Internet in 1988 “
> - Could these two be combined?

Probably - I’ll check.

> --
> - I suspect the sentence mentioning IPv6 

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

[Joe Touch]

> 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 protovcol.
>> 
>> Stream transports already do this for the entire stream.
>> 
>> The only other exception might be DCCP - I'd have to check that.
>> 
> IPsec, GRE, MPLS, Ether/IP, IPIP, etc.

These are not transport protocols. My point is that your proposal doesn’t help 
transports.

If a transport can avoid net-level frag, it’s always better to do so (see 
PLPMTUD).

> The whole point of having
> things like fragmentation into the network layer

Yes - at the network layer for those. Which is what IPv4 and IPv6 already 
support. 

Your proposal buries a pseudo-net layer inside a transport - at which point we 
don’t need the pseudo-net layer, at least not for fragmentation.

> is that it applies to
> all protocols and we don't need to "reinvent the wheel" every time a
> new protocol comes along.
> 
>>> Also, I don't understand how the fragmentation
>>> extension header, which has been defifor over twenty years and is
>>> now part of an Internet standard, can be called "obscured layering".
>> 
>> Not IPv4; the one where the network EHs would be buried after a GUE
>> transport header.
> 
> If by "network EHs" you mean Hop-by-Hop options, the draft specifies
> how intermediate nodes can parse them in the GUE payload, and a magic
> number is used to ensure with high probability that a middlebox is
> indeed inspecting a GUE packet.

Yes - boxes that don’t do IPv4 options for performance reasons will *magically* 
now support this extra work (thus the magic number?)

You specify how that can be done by examining headers nobody currently 
supports. So when (or if) nodes upgrade, they’ll be able to do something they 
currently refuse to do (that is simpler).

> Also, there is no requirement that any
> intermediate nodes must process IPv4 Hop-by-Hop options.

RFC1812:

4.2.2.1 <https://tools.ietf.org/html/rfc1812#section-4.2.2.1> Options: RFC 791 
Section 3.2 <https://tools.ietf.org/html/rfc791#section-3.2>

   In datagrams received by the router itself, the IP layer MUST
   interpret IP options that it understands and preserve the rest
   unchanged for use by higher layer protocols.

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 fragmentation
> extension header, which has been defined for over twenty years and is
> now part of an Internet standard, can be called "obscured layering".

Not IPv4; the one where the network EHs would be buried after a GUE
transport header.

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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.
>> I heard someone on another list argue strongly for fixed headers of the
>> sort IPv4 already uses. ;-)
>>
>>> 2) Encapsulate extension headers and following transport packet in GUE/UDP
>> Which, as I noted, undermines the useful work performed by firewalls.
>>
> Joe,
>
> Then so does QUIC, TLS, IPsec and anything else that would obfuscate
> the data that firewalls might want to inspect.

Of those, only IPsec hides application transport numbers. And your
proposal - though not encrypted, it buries them far enough that
firewalls won't go looking.

>  You seem to be
> convoluting firewalls and security,

Security has 4 dimensions:

- privacy

- integrity

- authentication (identity)

- resource protection

Firewalls help with the 4th dimension. It's still called security and
they're still very widely used (much more widely than any support likely
to come of new IP EHs, I'll happily wager).

And I know there are some in 6man talking about deployment. There were
those who started to deploy Active Nets in the 1990s too. Wouldn't they
be just as effective for what you want?

Oh, wait - they' were fringe at best and disappeared. Curious why...

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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.

Agreed, but if UDP supports fragmentation (it will), then we don't need
that capability buried in obscure layering.

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 and following transport packet in GUE/UDP

Which, as I noted, undermines the useful work performed by firewalls.

All so we can have routers process options - something they basically
don't do anyway...(I don't know who's pushing otherwise in 6man, but
this issue has been a big one for *many* years)

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 drop fragments, some will drop packets
> with IP options, some will drop ICMP, some will drop UDP packets with
> surplus space, some will parse into HTTP and drop packets with URLs
> they don't like, some will drop anything else they please. That's
> reality. But, DPI in the network => ossification => Internet doesn't
> evolve. IMO, we need to address this instead of just accepting it as
> status quo,

Firewalls are critical network security devices - even when they’re located 
within the client hosts’ control (e.g., enterprise edge) and thus more 
E2E-‘compliant’, they currently filter by server port number (i.e., TCP SYN 
dest port) - which your solution buries in a chain.

Your proposal provides port numbers for demuxing (substantially fewer per 
endpoint, because it would fix the server port as GUE), but buries the 
transport type far enough that intermediate devices would more likely “give up” 
and drop packets than go diving for it.

> lest plain TCP/IPv4 is the only thing left that works on
> the Internet. Transport layer encryption, extending happy eyeballs
> approach to other features, limited domains, showing value in forward
> looking features, using the architecturally correct methods of host to
> network signalling-- are ways to start undoing the harmful effects of
> ossification.

If you’re on a quest to avoid ossification, you’re digging in the wrong place 
and you might not want the result you get.

Ossification is never fixed by providing “yet another” way to do something we 
already can do.

And, importantly, one person’s ossification is another’s “stable foundation” 
that ensures interoperability (i.e., one layer up). So a solution needs to 
address a real need in a way that we actually expect will be deployed and used.

The solution proposed here intends to increase work by intermediate devices 
that have made it very clear they barely want to do forwarding (high speed 
routers), obscures information needed by intermediate devices for security (by 
burying the transport port at an unpredictable offset), and offers a network 
solution to a problem we already understand is better solved at the transport 
layer (fragmentation and reassembly).

So, even after this detailed discussion, we're back where I started - asking 
“where’s the need”?

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 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
>> ought to solve all these issues in one shot.
>> 
>> So what's the gain here?
>> 
>> 
>> Joe,
>> 
>> Please view the proposal in its entirety.
>> 
>> 
>> Here are the problems, which I already stated, but seem to need restating in 
>> the exact context of the proposal:
>> 
>> - IP options already cause routers to drop traffic
>>  this is true for both IPv4 and IPv6; making those options look like IPv6 
>> just gives routers a different WAY to drop them
>> 
> Some routers drop extension headers, but not all of them.

See RFC 7126.

> If all of
> them drop extension headers, then a whole bunch of effort in 6man is
> pointless.

No argument there.

> 
>> - DPI looks for transport port numbers that are expected, either for service 
>> gating or even deeper DPI
>>  and GUE isn't one of them
>> 
> There's no requirement to support DPI into the transport layer.

Sure, but the current problem is that mechanisms that defeat DPI can result in 
traffic being blocked.

> In
> fact, encryption of the transport layer, like in QUIC, effectively
> renders DPI into the transport layer useless.

Yes, but not the transport ports.
> ...
> 
>> - pushing the actual UDP port numbers used inside a GUE header creates an 
>> "internet in an internet"
>>  as noted above, that's a losing battle we've repeatedly tried
> 
> I'm not sure what you mean by "actual UDP port numbers”.

The E2E transport being used, rather than the encapsulation layer that you need 
to create a place between IP and transport for these options as if they were 
protocols.

The issue is that DPI that allows port 443 (even encrypted) and a finite set of 
other ports would likely block the GUE port. And it wouldn’t dive in to the 
sequence of headers to find the “actual” transport port inside.

— 

What we know so far is that:
- for on-path signaling, routers don’t want to be signaled or interacted with; 
they’re too busy just forwarding packets
- the only other reason for these headers are endpoint features that can - and 
IMO should - be done at the transport layer

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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
>> ought to solve all these issues in one shot.
>> 
>> So what's the gain here?
> 
> Joe,
> 
> Please view the proposal in its entirety.

Here are the problems, which I already stated, but seem to need
restating in the exact context of the proposal: 

- IP options already cause routers to drop traffic 
  this is true for both IPv4 and IPv6; making those options look like
IPv6 just gives routers a different WAY to drop them 

- DPI looks for transport port numbers that are expected, either for
service gating or even deeper DPI 
  and GUE isn't one of them 

- pushing the actual UDP port numbers used inside a GUE header creates
an "internet in an internet" 
  as noted above, that's a losing battle we've repeatedly tried 

Yes, this may be *intended* for uses other than fragmentation, but will
any of them succeed? Will even the fragmentation one succeed? 

That's the point I was trying to make. I hope it's clear enough now. 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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)?
>>
> Joe,
>
> The size of the IP identifier is mentioned as one of the problems with
> IPv4 fragmentation in draft-ietf-intarea-frag-fragile. 

That could have been handled by new rules to drop incompletely
reassembled datagrams based on measured expected reordering, rather than
max lifetime.

> The fact that
> intermediate nodes might fragment in IPv4 and not in IPv6 is another
> discrepancy between the protocols. 

Well, strictly the difference is only whether intermediate nodes violate
IPv4 or IPv6. IPv4 with DF isn't supposed to be on-path fragmented any
more than IPv6 is; in both cases, nodes that violate the protocols can -
and will - do whatever they want.

But there's no point in making "laws for the lawless", as I've
repeatedly noted throughout the IETF.

> The transport layer not in all
> fragments is a problem for NAT, that might addressed by encapsulating
> the fragmention in UDP.

That is a problem for NAT and transport-based ECMP.

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
ought to solve all these issues in one shot.

So what's the gain here?

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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. 

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 levels they think they expect, but that’s it.

There are no “guarantees” unless the operator controls the hosts that generate 
traffic that enters their network. This document should not refer to such 
guarantees or assurances.

Joe



> On Feb 12, 2019, at 4:20 PM, Ron Bonica  wrote:
> 
> Hi Eric,
> 
> Most network providers abide by the policy that you describe. If all of their 
> interior links support an MTU of N, their access links support an MTU of N 
> minus M, where M is the highest possible encapsulation overhead.
> 
> This guarantees that MTU issues never occur on interior links. However, MTU 
> issues can occur on provider access links. So, we still need to think about 
> mitigations, and whether fragmentation is an attractive mitigation.
> 
>Ron
> 
>> -Original Message-
>> From: Erik Kline 
>> Sent: Tuesday, February 12, 2019 1:26 PM
>> To: Ron Bonica 
>> Cc: int-area@ietf.org
>> Subject: Re: [Int-area] Comment on draft-ietf-intarea-frag-fragile-02
>> 
>> I think in that case it's just ensuring the MTU given to the customer via 
>> their
>> access link can be carried through their network without, or which a minimum
>> of, fragmentation.
>> 
>> I finally found some text to which I was referred, in 3GPP TS 29.060
>> (GTP) v15.2.0 section 13.2:
>> 
>>All backbone links should have MTU values that exceeds the sum of the
>> maximum value plus the size of the tunnel headers (IP header, UDP and GTP
>> header) in order to avoid fragmentation in the backbone.
>> 
>> In this case the "fit for purpose" is clearly delineated as "carrying GTP 
>> traffic".
>> 
>> I'll have to think about better text that "fit for purpose".  Can we say that
>> network operators who can characterize effectively the MTU requirements of
>> traffic traversing their network should factor in whatever overhead their
>> operational model requires so as to minimize, or preferably eliminate, the
>> need for fragmentation.
>> 
>> Operators that can't characterize the MTU requirements of their customer
>> traffic can decide if they're going to try or not, or care or not. :-)
>> 
>> On Tue, 13 Nov 2018 at 12:35, Ron Bonica  wrote:
>>> 
>>> Hi Erik,
>>> 
>>> Could you refine the recommendation a little bit? If an ISP were to ask,
>> "What MTU is fit for my purpose?", how would we answer?
>>> 
>>>  Ron
>>> 
>>> 
 Ron,
 
 Related to this section, at the mic I was suggesting perhaps
 including some simple text recommending that network operators
 SHOULD take efforts to make sure the MTU(s) on their network(s) are
 "fit for purpose", i.e. sized to avoid fragmentation to the extent 
 possible.
 
 I'm not sure yet how to better express that notion.  It seems
 obvious and anodyne, but it can be useful to have these things
 captured for reference by non-IETF documents.
>>> *
>>> 
>>> ___
>>> Int-area mailing list
>>> Int-area@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>>> man_listinfo_int-2Darea=DwIBaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-
>> ndb3voD
>>> TXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-
>> AWF2EfpHcAwrDThKP8=emFLkzGIF-fQ7
>>> S48Z8rD2NpAlgzoAvIzozz0t7qvL2I=xl1riR8LmiMwXl2df4Uy117M-
>> mozqtV6eXJJl
>>> rue5DI=
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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
>>  
>> 
>> is a little more interesting in that it provides a few more details.
>> In particular the requirement that all fragments must traverse the
>> same intermediate device is mentioned:
>> 
>> "The reassembly process requires all fragments within an IP datagram.
>> If fragments within an IP datagram are sent to different devices due
>> to load balancing VFR may fail and fragments may be dropped."
> 
> Yes, of course the fragments all need to go through the same destination where
> VFR is caching the fragments. 

This isn’t any different from the fact that middle boxes don’t react well to 
multipathing of IP packets that ignores flow info, e.g., when all packets of a 
TCP connection or UDP flow don’t go through the same middle box.

As per my other message, the per-packet processing load isn’t all that 
different EXCEPT to queue fragments before the first-frag is seen.

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 in reassenbly cache
>  if found
> forward buffered packets
>  else
>create session state entry in reassembly cache
>forward packet
> else
>  found = lookup 4 tuple in reassembly cache
>  if found
>forward packet
>  else
>buffer packet

The only addition to the pseudocode above is to timeout the cache entries based 
on the “expected reordering” (see RFC 6864). That timeout performs the same 
function as the TCP cache entry timeout in those NATS/firewalls.

For TCP, a FIN-ack or ack after FIN (depending on who closes the connection) 
can flush the entry before a timeout. For fragment reassembly, the middle box 
CAN keep track of the fragments seen and flush the entry when a complete 
“virtually reassembled” packet is seen, but that’s probably overkill vs. a 
simple timer (actually, a packet count can suffice).

Joe





___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 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 later in the recommendations. The sentences you remove were 
>> the only thing that tied the two together, which IMO is important.
>> 
>> 
>> Joe,
>> 
>> The term "Stateless firewalls" is unambiguous in this context. In a
>> stateless firewall, each packet is inspected and judge based solely on
>> it's content.
>> 
>> 
>> My statement above has no relation to any potential ambiguity in the term.
>> 
>> ---
>> 
>> However, the term stateless is inaccurate in a few places:
>> 
>> (Sec 4.6) NAT is a stateful procedure for an otherwise stateless protocol as 
>> well. The same could be argued for load balancers that retain similar state 
>> through a connection for a flow (i.e., not just hashing the flow or tuple, 
>> but doing round-robin per-flow/tuple 'sticky' routing)
>> 
>> (Sec 7.3) The problem is not just stateless middle boxes, but also certain 
>> stateful ones (e.g., NATs, some load balancers, etc.)
>> 
>> ---
>> 
>> Thus "stateful" actually is both ambiguous and inaccurate here.
>> 
>> You appear to want to distinguish between the state needed for virtual 
>> reassembly and the state needed to maintain NAT translations or sticky 
>> round-robin load balancing, but there's no simple term that differentiates 
>> them. They're both content-dependent, context-dependent, and stateful.
>> 
>> 
>> Further, as you note there are no *specified* algorithms for virtual 
>> reassembly, nor are there any *specified* for NAT translation table 
>> maintenance or sticky load balancing. Everyone comes up with their own and 
>> the basic concept is well enough defined as to not need a specification.
>> 
> In that case, if it's so obvious and well defined then there shouldn't
> be any issue in either providing a reference to a description or
> specifying it in the draft (if authors do choose discuss virtual
> reassembly in the draft).
> 
> Tom
> 
>> Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 later in the recommendations. The sentences you remove were 
>> the only thing that tied the two together, which IMO is important.
> 
> Joe,
> 
> The term "Stateless firewalls" is unambiguous in this context. In a
> stateless firewall, each packet is inspected and judge based solely on
> it's content.

My statement above has no relation to any potential ambiguity in the
term. 

--- 

However, the term stateless is inaccurate in a few places: 

(Sec 4.6) NAT is a stateful procedure for an otherwise stateless
protocol as well. The same could be argued for load balancers that
retain similar state through a connection for a flow (i.e., not just
hashing the flow or tuple, but doing round-robin per-flow/tuple 'sticky'
routing) 

(Sec 7.3) The problem is not just stateless middle boxes, but also
certain stateful ones (e.g., NATs, some load balancers, etc.) 

--- 

Thus "stateful" actually is both ambiguous and inaccurate here. 

You appear to want to distinguish between the state needed for virtual
reassembly and the state needed to maintain NAT translations or sticky
round-robin load balancing, but there's no simple term that
differentiates them. They're both content-dependent, context-dependent,
and stateful. 

Further, as you note there are no *specified* algorithms for virtual
reassembly, nor are there any *specified* for NAT translation table
maintenance or sticky load balancing. Everyone comes up with their own
and the basic concept is well enough defined as to not need a
specification. 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 that draft-tunnels points out significant issues in some of the RFCs 
cited here, e.g., 4459. Part of the reason why fragmentation doesn’t work well 
is the errors in those prior docs.

Joe

> On Jan 30, 2019, at 6:20 PM, Ron Bonica  wrote:
> 
> Done
> 
>> -Original Message-
>> From: Tom Herbert 
>> Sent: Wednesday, January 30, 2019 7:56 PM
>> To: Ron Bonica 
>> Cc: int-area@ietf.org; Brian E Carpenter 
>> Subject: Re: I-D Action: draft-ietf-intarea-frag-fragile-06.txt
>> 
>> On Wed, Jan 30, 2019 at 12:57 PM Ron Bonica  wrote:
>>> 
>>> Inline..
>>> 
 Message: 3
 Date: Tue, 29 Jan 2019 11:45:45 -0800
 From: Tom Herbert 
 To: int-area 
 Subject: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06
 Message-ID:
  >>> t4m5b55yayl+np4...@mail.gmail.com>
 Content-Type: text/plain; charset="UTF-8"
 
 Hello,
 
 I have suggested text for the draft to address some previous
 comments made on the list.
 
 Last paragraph in section 4.3:
 
 "This problem does not occur in stateful firewalls or Network
 Address Translation (NAT) devices. Such devices maintain state so
 that they can afford identical treatment to each fragment that
 belongs to a packet. Note, however, that stateful firewalls and NAT
 devices impose the external requirement that all packets of a flow
 and fragments of a packets for a flow must traverse the same stateful
>> device; stateless devices do not force this requirement."
 
>>> 
>>> The first two sentence that you suggest already appear in version 06 of the
>> document.
>>> 
>>> I would prefer to omit the final sentence for the following reasons:
>>> 
>>> - It isn't absolutely necessary
>>> - It opens another can of worms that I don't want to address. Specifically,
>> some stateful firewalls perform virtual reassembly but don't maintain TCP
>> session state. Some stateful firewalls perform virtual reassemble and 
>> maintain
>> TCP state. You third sentence is true for one firewall type and false for the
>> other.
>>> 
>> Yes, but as Fred mentioned, the current text is a blanket statement that
>> stateful firewalls don't have this problem. Some firewalls may have
>> implemented virtual reassembly, but others may not and might not do
>> anything we'd consider reasonable for handling fragments. So similarly the
>> statement in the draft may be "true for one firewall type and false for the
>> other". Also, any implication that people should swap out their stateless
>> devices for stateful ones because they solve one problem without mentioning
>> that they introduce other problems would be a disservice IMO.
>> 
>> To avoid the can of worms, I suggest the whole paragraph and any discussion
>> about stateful devices could be removed from the draft without loss of
>> content.
>> 
>> Tom
>> 
 Section 4.5:
 "IP fragmentation causes problems for some routers that support
 Equal Cost Multipath (ECMP). Many routers that support ECMP execute
 the algorithm described in Section 4.4 in order to perform flow
 based forwarding; therefore, the exhibit they same problematic
 behaviors described in Section 4.4. In IPv6, the flow label may
 alternatively used as input to the algorithm as opposed to parsing
 the transport layer of packets to discern port numbers. The flow
 label should be consistently set for a packets of flow including
 fragments, such that a device does not need to parse packets beyond the
>> IP header for the purposes of ECMP."
>>> 
>>> This comment is almost identical to one made by Brian Carpenter. I have
>> addressed his comment in Section 4.4. Rather than repeating the same text in
>> Section 4.5, I have merged the two sections.
>>> 
 
 Add to section 7.3:
 
 "Routers SHOULD use IPv6 flow label for ECMP routing as described in
 [RFC6438]."
>>> 
>>> Brian suggested similar text, but in a new section. Look for the new
>>> section in version 07
>>> 
>>> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 
>> through only one of those boxes, treating it as the host it is, everything 
>> works fine.
>> 
>> That’s why it IS a host. And why I don’t need new rules to understand or 
>> explain it.
>> 
> Joe,
> 
> You just stated a new rule. In order for these devices to work we need
> to "limit the paths to go through only one of those boxes".

Sticking a phone in a pot of dirt doesn’t make it a houseplant.

Putting these devices where hosts don’t work doesn’t make them routers or 
anything else.

The rules are simple. If it is a host , it must be run like a host.

If the only way it runs correctly is to act like a host, it is a host.

The Internet doesn’t have a rule that says you can do anything you want. Play 
by the rules or the system doesn’t work.

> If a user
> deploying a network doesn't follow this rule they will be in a world
> of hurt when things start to fail.

Exactly like sticking the phone in a pot of dirt ruins the phone.

> Even if someone understands the
> rule, consistently routing flows in even a moderately complex network
> is a hard problem.

Yes, when you keep sticking phones in pots of dirt, it’s hard to use the phones.

> This is one reason why transport layer proxies are
> popular. They are hosts, addressees of packets, in the network that
> terminate transport layer protocols and don't require consistent
> routing (but they do entail other complexities).

Non-transparent proxies force users to treat the boxes as hosts, and magically 
everything starts working again.  Go figure.

Joe

> 
> Tom
> 
> 
> Tom
> 
> 
>> 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 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 which is that packets for some flow
>>>> must consistently the traverse the same intermediate node.
>>>> 
>>>> 
>>>> It’s not an intermediate node - it’s a host. It’s the same requirement as 
>>>> any host - that a host has one point of attachment to a network for a 
>>>> given IP address.
>>>> 
>>>> In any case, as I said previously, reassembly is only specified as an
>>>> operations at destination hosts.
>>>> 
>>>> 
>>>> And these are destination hosts because of how they behave, which means 
>>>> they need to reassemble (either actually or logically).
>>>> 
>>>> It seems like there might be a need
>>>> for in-network reassmbly, or some nodes might be doing it already.
>>>> 
>>>> 
>>>> It’s not in-network - it’s at a host, but yes, some do reassemble (or its 
>>>> equivalent).
>>>> 
>>>> 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 an “intermediate” node. Never was.
>>>> 
>>> Joe,
>>> 
>>> You can try this experiment. Provision two stateful firewalls as
>>> egress points of a network. From an internal network network host
>>> connect to an external host of the network. Now changing routing. If
>>> packets to the external network were being routed through firewall A,
>>> changing routing so they go through firewall B. Now take a look at
>>> what happens to packets on the connection. They are dropped at
>>> firewall B because it does not have the connection state that firewall
>>> A has. The connection is no longer viable. You can call these devices
>>> whatever you want, but that doesn't change the fact that stateful
>>> devices in the network, including those that attempt reassembly, break
>>> multi-path.
>>> 
>>> Tom
>>> 
>>>> Joe
>> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 through only one of 
those boxes, treating it as the host it is, everything works fine.

That’s why it IS a host. And why I don’t need new rules to understand 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 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 which is that packets for some flow
>> must consistently the traverse the same intermediate node.
>> 
>> 
>> It’s not an intermediate node - it’s a host. It’s the same requirement as 
>> any host - that a host has one point of attachment to a network for a given 
>> IP address.
>> 
>> In any case, as I said previously, reassembly is only specified as an
>> operations at destination hosts.
>> 
>> 
>> And these are destination hosts because of how they behave, which means they 
>> need to reassemble (either actually or logically).
>> 
>> It seems like there might be a need
>> for in-network reassmbly, or some nodes might be doing it already.
>> 
>> 
>> It’s not in-network - it’s at a host, but yes, some do reassemble (or its 
>> equivalent).
>> 
>> 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 an “intermediate” node. Never was.
>> 
> Joe,
> 
> You can try this experiment. Provision two stateful firewalls as
> egress points of a network. From an internal network network host
> connect to an external host of the network. Now changing routing. If
> packets to the external network were being routed through firewall A,
> changing routing so they go through firewall B. Now take a look at
> what happens to packets on the connection. They are dropped at
> firewall B because it does not have the connection state that firewall
> A has. The connection is no longer viable. You can call these devices
> whatever you want, but that doesn't change the fact that stateful
> devices in the network, including those that attempt reassembly, break
> multi-path.
> 
> Tom
> 
>> Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 an “intermediate” node. Never was.
> 
> Joe

FWIW, another way of looking at the problem is this:

- if it was bound to the rules of a host, would it work? Would that be enough 
to specify it’s constraints?

If so, then maybe that’s further evidence of what it *is*, regardless of what 
it is sold as.

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 which is that packets for some flow
> must consistently the traverse the same intermediate node.

It’s not an intermediate node - it’s a host. It’s the same requirement as any 
host - that a host has one point of attachment to a network for a given IP 
address.

> In any case, as I said previously, reassembly is only specified as an
> operations at destination hosts.

And these are destination hosts because of how they behave, which means they 
need to reassemble (either actually or logically).

> It seems like there might be a need
> for in-network reassmbly, or some nodes might be doing it already.

It’s not in-network - it’s at a host, but yes, some do reassemble (or its 
equivalent).

> 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 an “intermediate” node. Never was.

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 arrives on your interface that isn't destined
>> to your IP address, you ARE NOT a host.
>> 
>> Correct. Note that the association of host with traffic counts for both 
>> transmission and reception, though.
>> 
>> I suspects that
>> implementations of in-network reassembly commonly make two incorrect
>> assumptions:
>> 
>> The first one is above...
>> 
>> 1) All fragments of a packet traverse the network device performing 
>> reassembly
>> 2) The first fragment is always received first
>> 
>> Neither of these assumptions are valid for IP.
>> 
>> Agreed, but again, there are three incorrect assumptions. The first is that 
>> a NAT isn't a host, and too often that's the one that causes the above two 
>> to actually cause pain.
>> 
>> If NAT is a host, then it is only a host in the return path. Packets
>> sent from the client behind a NAT have destinations addresses that are
>> not those of the the NAT device. If a device is performing host
>> procedures on such packets, like reassembly, then it is being done
>> outside the auspices of the standard.
>> 
>> Not quite. The return path is certainly easier to see, but the forward path 
>> doesn't *relay* the incoming packets; it consumes them. Which is what a host 
>> does.
>> 
>> The outgoing packets are emitted with the source IP of the NAT. So in the 
>> forward direction, strictly, only the *content* is relayed.
>> 
>> If that content is modified (i.e., address/port rewriting) or inspected, 
>> then that device is acting as a host.
>> If the outgoing HOST packets depend on something of the incoming ones, then 
>> that device is also acting as a host.
>> 
>> In any case, this isn't a NAT specific issue. Stateful firewalls
>> regularly process packets for which they aren't the destination.
>> 
>> And they are similarly bound by the rules of being a host *when they do*.
> Joe,
> 
> That's impossible. The first rule is that a host is defined as a node
> to which packets are addressed.

A second rule - per RFC 1812 - is that forwarding devices modify only
the opcount and certain IP options. 

> Intermediate nodes performing host
> processing on packets that don't have their address have already
> violated rule #1.

They consume those packets, they are acting as if they think all
outgoing dest addresses are theirs and assigned to their interface.
I.e., from the outside, they act exactly as if their interface has ALL
those addresses. 

> If they're keeping flow state in the network
> (connection state or reassembly), then that inevitably forces the
> requirement that packets have to be routed through a particular node
> in order for state to be maintained.

Agreed. And because they act as host, they fail badly when they're not
deployed under host assumptions and requirements. 

> This is not a problem hosts have,

It is - that's implicit in the function of their reassembly mechanism
and a reason why it's hard to deploy "virtual" hosts that live in
multipe places on the network (e.g., for single-IP load balancing server
farms, for virtual deployment of copies of a single IP in multiple
places, etc.) 

> and it's not required in IP that packets of a flow have to always take
> the same path to a destination.

Path, no - agreed. But *destination*, yes. Again, the host *is* the
destination. 

> Without additional requirements on
> deployment, stateful devices break multi-path.

Other way around; multipath breaks stateful devices (they don't work as
desired) when they're not deployed *as the hosts they actually are and
always have been* (at least when they perform certain functions we're
talking about there). 

> So if these devices need to *emulate* host behaviors then there really
> should be a specification to that effect.

When you act as a host, you have to follow the rules of being a host. 

> It's not enough to simply
> say they have to follow host requirements. 
> 
> They can't and they clearly
> impose additional requirements.

I agree they don't; it's clear they CAN (it would be costly). 

They don't impose any new requirements beyond being the host they are,
though. 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 destinations has been. 
> Hint - if a packet arrives on your interface with your IP address, you ARE a 
> host.
 Joe,

Conversley, if a packet arrives on your interface that isn't destined
to your IP address, you ARE NOT a host. 

Correct. Note that the association of host with traffic counts for both
transmission and reception, though. 

> I suspects that
> implementations of in-network reassembly commonly make two incorrect
> assumptions: 
> The first one is above... 
> 1) All fragments of a packet traverse the network device performing reassembly
> 2) The first fragment is always received first
> 
> Neither of these assumptions are valid for IP. 
> Agreed, but again, there are three incorrect assumptions. The first is that a 
> NAT isn't a host, and too often that's the one that causes the above two to 
> actually cause pain.
 If NAT is a host, then it is only a host in the return path. Packets
sent from the client behind a NAT have destinations addresses that are
not those of the the NAT device. If a device is performing host
procedures on such packets, like reassembly, then it is being done
outside the auspices of the standard. 

Not quite. The return path is certainly easier to see, but the forward
path doesn't *relay* the incoming packets; it consumes them. Which is
what a host does. 

The outgoing packets are emitted with the source IP of the NAT. So in
the forward direction, strictly, only the *content* is relayed. 

If that content is modified (i.e., address/port rewriting) or inspected,
then that device is acting as a host. 
If the outgoing HOST packets depend on something of the incoming ones,
then that device is also acting as a host. 

> In any case, this isn't a NAT specific issue. Stateful firewalls
> regularly process packets for which they aren't the destination.

And they are similarly bound by the rules of being a host *when they
do*. 

The Internet requirements work just fine; its the devices that aren't
following them. 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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:
>> 
>>> 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."
>> 
>> This requirement is confusing to me on several accounts. First of all,
>> there are a lot of requirements about fragmentation in both RFC791 and
>> RFC8200, including some MUSTs. This requirement seems to be updating
>> and possibly relaxing some of those requirements, but is not specific.
>> 
>> I disagree; being compliant with existing RFCs neither updates nor relaxes 
>> those RFCs.
>> 
>> This seems ambiguous as a normative requirement.
>> 
>> Perhaps vague, agreed.
>> 
>> Secondly, the only specified interaction between fragmentation and
>> intermediate nodes is that routers can fragment packets in IPv4.
>> 
>> Agreed. However, nodes that *create* packets with their own IP addresses act 
>> as hosts; in that regard, middleboxes act both as intermediate (from the 
>> private side to public) and hosts (from the public side). As hosts, packets 
>> entering them, destined to *their* IP addresses, need to be reassembled, 
>> just as with any other host.
>> 
>> This is addressed in detail here:
>> 
>> Touch, J,. "Middlebox Models Compatible with the Internet," Technical 
>> Report, USC/ISI (ISI-TR-711), 2016.
>> 
>> https://www.strayalpha.com/pubs/isi-tr-711.pdf
>> 
>> Other
>> than that, a middlebox that complies with RFC791 and RFC8200 does not
>> process or consider fragmentation of packets. Given that, it's unclear
>> to me why middle boxes would need to maintain state to be protocol
>> compliant.
>> 
>> If they process only IP headers, they don't. If they further consume the 
>> packet's contents - as would a *host*, they need to reassemble that content 
>> (even if virtually) to be able to interpret it. That includes associating 
>> transport headers with all the content as well as inspecting that content.
>> 
> Joe,
> 
> As I mentioned, in-network reassembly has not been specified, only
> reassembly at end destinations has been.

Hint - if a packet arrives on your interface with your IP address, you ARE a 
host.

> I suspects that
> implementations of in-network reassembly commonly make two incorrect
> assumptions:

The first one is above...
> 
> 1) All fragments of a packet traverse the network device performing reassembly
> 2) The first fragment is always received first
> 
> Neither of these assumptions are valid for IP.

Agreed, but again, there are three incorrect assumptions. The first is that a 
NAT isn’t a host, and too often that’s the one that causes the above two to 
actually cause pain.

> 
>> It's possible that the implicit exception of the
>> requirement is that middleboxes might perform "in-network reassembly"
>> or "virtual reassemlby" which would require state. If that is indeed
>> the case then the requirements for the mechanisms should be spelled
>> out.
>> 
>> As with Ron, I agree that seems out of scope for this doc.
>> 
>> For stateless load balancing (described in section 4.4), the IPv6 flow
>> label obviates the need for DPI.
>> 
>> Only for flow-based routing; not for DPI processing involving content beyond 
>> the transport header, e.g., content-based routing. I.e., it depends on how 
>> far into the packet the DPI is going...
>> 
> TLS and payload encryption have largely eliminated the ability for
> intermediate devices to perform DPI into content. Transport layer
> header encryption, like done in QUIC, will further reduce the value of
> doing DPI.

Yes and no; there are still devices that do DPI on content - especially devices 
that spoof the initial splash page for Internet access when at hotspots. Some 
of them won’t even open a splash page unless customers first access a non-TLS 
website.

Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 the firewall drop rules are based on information
available in the first fragment. The D in DPI often goes much further.

Joe


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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."
>
> This requirement is confusing to me on several accounts. First of all,
> there are a lot of requirements about fragmentation in both RFC791 and
> RFC8200, including some MUSTs. This requirement seems to be updating
> and possibly relaxing some of those requirements, but is not specific.
I disagree; being compliant with existing RFCs neither updates nor
relaxes those RFCs.
> This seems ambiguous as a normative requirement.
Perhaps vague, agreed.
> Secondly, the only specified interaction between fragmentation and
> intermediate nodes is that routers can fragment packets in IPv4.

Agreed. However, nodes that *create* packets with their own IP addresses
act as hosts; in that regard, middleboxes act both as intermediate (from
the private side to public) and hosts (from the public side). As hosts,
packets entering them, destined to *their* IP addresses, need to be
reassembled, just as with any other host.

This is addressed in detail here:

Touch, J,. "Middlebox Models Compatible with the Internet," Technical
Report, USC/ISI (ISI-TR-711), 2016.

https://www.strayalpha.com/pubs/isi-tr-711.pdf

> Other
> than that, a middlebox that complies with RFC791 and RFC8200 does not
> process or consider fragmentation of packets. Given that, it's unclear
> to me why middle boxes would need to maintain state to be protocol
> compliant. 
If they process only IP headers, they don't. If they further consume the
packet's contents - as would a *host*, they need to reassemble that
content (even if virtually) to be able to interpret it. That includes
associating transport headers with all the content as well as inspecting
that content.
> It's possible that the implicit exception of the
> requirement is that middleboxes might perform "in-network reassembly"
> or "virtual reassemlby" which would require state. If that is indeed
> the case then the requirements for the mechanisms should be spelled
> out.
As with Ron, I agree that seems out of scope for this doc.
> For stateless load balancing (described in section 4.4), the IPv6 flow
> label obviates the need for DPI. 
Only for flow-based routing; not for DPI processing involving content
beyond the transport header, e.g., content-based routing. I.e., it
depends on how far into the packet the DPI is going...
> It is sufficient to hash over the
> three tuple  to get good load balancing. All
> major OSes have been updated to set flow labels, and there are devices
> that already support this. IMO, the draft should make using flow label
> for stateless load balancing a SHOULD.
>
> Tom
>
> On Mon, Jan 14, 2019 at 11:55 AM Joel M. Halpern  wrote:
>> I have re-read this document.  I think it is a useful document that
>> captures that state of a complex tradeoff and makes effective
>> recommendations. I support publishing it as a BCP.
>>
>> If the authors make further additions, adding a mention of ECMP as a
>> particular case of stateless load balancers might further improve the
>> document.
>>
>> Yours,
>> Joel
>>
>> On 1/14/19 1:13 PM, Wassim Haddad wrote:
>>> Dear all,
>>>
>>> This email starts an Int-Area WG Last Call on the latest version of "IP 
>>> Fragmentation Considered Fragile” draft:
>>>
>>> https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-05
>>>
>>> Please respond to this email to support the document and/or send comments 
>>> by 2019-01-28.
>>>
>>> Please indicate if you are personally aware of any IPR that applies to 
>>> draft-ietf-intarea-frag-fragile-xx?
>>> If so, has this IPR been disclosed in compliance with IETF IPR rules?
>>>
>>>
>>> Regards,
>>>
>>> Juan & Wassim
>>> ___
>>> Int-area mailing list
>>> Int-area@ietf.org
>>> https://www.ietf.org/mailman/listinfo/int-area
>>>
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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. The promise of doing IP fragmentation at the
> network layer is that the application developer doesn't need to be
> concerned with such things

Agreed. That and issues with IP frag are why we’re developing UDP frag. 

Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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: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 fragment 
>>>> as low as possible)
>>> 
>>> That sounds like an unfounded myth. 
>>> I would think it highly dependent on implementation.  
>> 
>> Reality:
>> 
>> - every layer down you do it avoids a layer of header in-between *at every 
>> fragment*
>> ie., IP fragments have only ONE UDP header and ONE application header, but 
>> app-fragments have multiples of both.
>> 
>> Do the math.
> 
> Every ipv6 fragment has an additional 8 byte header.

For IPv6, yes (not for IPv4). But that only counters the extra UDP header; 
there’s still the application fragmentation header too.

> But the network might not be the bottleneck here, and a few more bytes might 
> not matter. As I said it depends. 
> When it comes to performance making blanket statements is rarely a good idea. 

Such as "When it comes to performance making blanket statements is rarely a 
good idea.”, agreed.

But it’s nowhere near an unfounded myth.

Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

> 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 fragment as 
>> low as possible)
> 
> That sounds like an unfounded myth. 
> I would think it highly dependent on implementation.  

Reality:

- every layer down you do it avoids a layer of header in-between *at every 
fragment*
ie., IP fragments have only ONE UDP header and ONE application header, but 
app-fragments have multiples of both.

Do the math.

Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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’s useful to not repeat effort and learning curves in each app

Add that to the fact that ti’s possible to improve lower layers without 
revising every app (i.e., shared benefit from updates).

Joe

> On Nov 30, 2018, at 7:40 AM, Christian Huitema  wrote:
> 
> 
> 
>> On Nov 30, 2018, at 7:25 AM, Templin (US), Fred L 
>>  wrote:
>> 
>> Right, we have talked about that. A disadvantage is that the application
>> framing headers need to be repeated in each UDP datagram, and when
>> the application headers are large the amount of room left for actual data
>> is diminished.
> 
> Seems like a weak argument. If the application is important and if 
> performance is an issue, the application should be updated.
> 
> -- Christian Huitema 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

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 Touch wrote:
>> They don’t need to be deleted if you include them deliberately. There is no 
>> prohibition on citing such RFCs for your own documents historical background.
>> 
>> Joe
>> 
>> On Nov 29, 2018, at 4:06 AM, Stewart Bryant  wrote:
>> 
>>> But, always worth including a "do be deleted" note to the 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,
>>>>> 
>>>>> If the NFSv2 and iPERF issues are not blocking, I would like to omit 
>>>>> them. The following are rational:
>>>>> 
>>>>> ...
>>>>> - Mechanically, it is difficult to reference an RFC that has been 
>>>>> obsoleted in an internet draft. The NIT checker complains bitterly.
>>>>  
>>>> Those complaints are warnings only to help those who cite such documents 
>>>> inadvertently; you can simply ignore them. (I do all the time - esp. for 
>>>> historical discussions that cite early versions of newer RFCs or 
>>>> historical standards).
>>>>  
>>>> Joe
>>>> 
>>>> 
>>>> ___
>>>> Int-area mailing list
>>>> Int-area@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/int-area
>>> 
> 
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

They don’t need to be deleted if you include them deliberately. There is no 
prohibition on citing such RFCs for your own documents historical background.

Joe

> On Nov 29, 2018, at 4:06 AM, Stewart Bryant  wrote:
> 
> But, always worth including a "do be deleted" note to the 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,
>>> 
>>> If the NFSv2 and iPERF issues are not blocking, I would like to omit them. 
>>> The following are rational:
>>> 
>>> ...
>>> - Mechanically, it is difficult to reference an RFC that has been obsoleted 
>>> in an internet draft. The NIT checker complains   bitterly.
>>  
>> Those complaints are warnings only to help those who cite such documents 
>> inadvertently; you can simply ignore them. (I do all the time - esp. for 
>> historical discussions that cite early versions of newer RFCs or historical 
>> standards).
>>  
>> Joe
>> 
>> 
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joe Touch]

FWIW:

On 2018-11-27 12:22, Ron Bonica wrote:

> Fred,
> 
> If the NFSv2 and iPERF issues are not blocking, I would like to omit them. 
> The following are rational:
> 
> ...
> - Mechanically, it is difficult to reference an RFC that has been obsoleted 
> in an internet draft. The NIT checker complains bitterly.

Those complaints are warnings only to help those who cite such documents
inadvertently; you can simply ignore them. (I do all the time - esp. for
historical discussions that cite early versions of newer RFCs or
historical standards). 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Stateless devices and IP fragmentation

[Joe Touch]

> On Nov 17, 2018, at 9:28 AM, Tom Herbert  wrote:
> 
> On Sat, Nov 17, 2018 at 9:09 AM Joe Touch  wrote:
>> 
>> 
>> 
>>> On Nov 17, 2018, at 9:00 AM, Tom Herbert  wrote:
>>> 
>>> On Fri, Nov 16, 2018 at 7:02 AM Ron Bonica  wrote:
>>>> 
>>>> Hi Brian,
>>>> 
>>>> Fair enough. Does the following text work?
>>>> 
>>>>  Ron
>>>> 
>>>> 7.3.  For Middle Box Developers
>>>> 
>>>> 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.
>>>> 
>>> Ron,
>>> 
>>> Devices that maintain protocol state in the network aren't protocol
>>> compliant either.
>> 
>> They’re called endpoints — exactly because that’s what they have to be 
>> acting like.
>> 
> If the destination address of a packet is a local address of the
> device then they are not endpoints. They are intermediate nodes.
> Stateful intermediate nodes do attempt to emulate some of the
> functions of an endpoint, but that requires non-standard assumptions
> and cannot be protocol conformant with host requirements.

They’re acting as if those addresses are theirs - otherwise, transport info 
would have no meaning (it is meaningful only between pairs of endpoints 
anyway). Consider that two endpoints can run DNS on port 80 - or can run a 
single TCP connection that rotates ports all day long. That’s entirely an 
endpoint decision.

I.e., the fact that they do anything beyond L3 *makes* them endpoints at those 
addresses.

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Stateless devices and IP fragmentation

[Joe Touch]

> On Nov 17, 2018, at 9:00 AM, Tom Herbert  wrote:
> 
> On Fri, Nov 16, 2018 at 7:02 AM Ron Bonica  wrote:
>> 
>> Hi Brian,
>> 
>> Fair enough. Does the following text work?
>> 
>>   Ron
>> 
>> 7.3.  For Middle Box Developers
>> 
>> 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.
>> 
> Ron,
> 
> Devices that maintain protocol state in the network aren't protocol
> compliant either.

They’re called endpoints — exactly because that’s what they have to be acting 
like.

> 
>> Price and performance considerations frequently motivate network operators 
>> to deploy stateless middle boxes.  These stateless middle boxes may perform 
>> sub-optimally, process IP fragments in a manner that is not compliant with 
>> RFC 791 or RFC 8200, or even discard IP fragments completely. Providers of 
>> such middle boxes MUST document product's their behavior.
> 
> This is too permissive for middle boxes to implement whatever ad hoc
> behavior they want. I would say it like:
> 
> "Price and performance considerations frequently motivate network
> operators to deploy stateless middle boxes.  Some deployed stateless
> middle boxes process IP fragments in a manner that is not compliant
> with RFC 791 or RFC 8200, or even discard IP fragments completely.
> Such behaviors are NOT RECOMMENDED. If a middleboxes implements
> non-standard behavior with respect to IP fragmentation, then that
> behavior MUST be clearly documented.”

That sounds OK to me - at least in the spirit of consensus.

> 
>> 
>> The behaviors exhibited by the above-mentioned devices are not desirable. 
>> However, one behavior may be acceptable to one network operator while 
>> another behavior is acceptable to another network operator. Middle box 
>> vendors MUST provide network operators with all of the information required 
>> to  make intelligent middle box deployment decisions.
> 
> I don't think this paragraph is needed with the suggested text above.

Agreed, FWIW.

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Stateless devices and IP fragmentation

[Joe Touch]

I respectfully then conclude that there is nothing "best" in this BCP. 

It certainly isn't even "current" practice. 

So, if we're speaking of documenting only procedures that (a) already
exist AND that (b) we want others to follow, it seems the path is clear
to simply pass on this document entirely. 

Joe

On 2018-11-15 14:30, Ron Bonica wrote:

> Joe, 
> 
> Respectfully, I think that this is beyond the scope of this document. This 
> document is a BCP describing the current state of IP Fragmentation. It is not 
> a PS document that describes new procedures and bits on the wire. 
> 
> Again, if you would like to work on such a document, I would be glad to work 
> on it with you. But it just doesn't belong in the current document. 
> 
> Chairs, 
> 
> We appear to be at an impasse. Advice? 
> 
> Ron 
> 
> FROM: Joe Touch  
> SENT: Thursday, November 15, 2018 5:24 PM
> TO: Ron Bonica 
> CC: Tom Herbert ; Brian E Carpenter 
> ; int-area 
> SUBJECT: Re: [Int-area] Stateless devices and IP fragmentation 
> 
> On 2018-11-15 13:35, Ron Bonica wrote: 
> 
> Tom, Joe, Brian,
> 
> I haven't seen a response to this message. Can I assume that you are OK with 
> this text?
> 
> Ron
> 
> -Original Message-
> From: Ron Bonica
> Sent: Wednesday, November 14, 2018 4:35 PM
> To: Tom Herbert 
> Cc: int-area ; Joe Touch 
> Subject: RE: [Int-area] Stateless devices and IP fragmentation
> 
> Folks,
> 
> We thrashing over the example. Can everybody agree to the following text?
> 
> Ron
> 
> 7.3.  For Middle Box Developers
> 
> 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.
> 
> Price and performance considerations frequently motivate network operators
> to deploy stateless middle boxes. These stateless middle boxes may perform
> sub-optimally or process IP fragments in a manner that is not compliant with
> RFC 791 or RFC 8200. Providers of such middle boxes MUST document
> product's their behavior.

I already noted that "documenting" that behavior isn't sufficient; IMO,
they MUST also provide at least occasional network signals to indicate
that non-compliance (as I noted, using reassembly timeout seems both
reasonable and of minimal collateral impact). 

>> The behaviors exhibited by the above-mentioned devices are not desirable.
>> However, one behavior may be acceptable to one network operator while
>> another behavior is acceptable to another network operator. Middle box
>> vendors MUST provide network operators with all of the information required
>> to  make intelligent middle box deployment decisions.

I might suggest "deployment and/or configuration", but sure. 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Stateless devices and IP fragmentation

[Joe Touch]

On 2018-11-14 13:20, Ron Bonica wrote:

> Joe, 
> 
> I half agree with you. Stateless middle boxes really should send feedback to 
> the source when they process fragments in funky ways. However, I don't think 
> that they should sent an ICMP Time Exceeded with code (1) reassembly time 
> exceeded. 
> 
> This message isn't exactly accurate. The middle box never attempted to 
> reassemble the packet and won't attempt to reassemble the packet if it 
> receives it again. We probably need a new ICMP message.

 That's fraught with its own problems, but that's not driving my
reasoning.

IMO, the issue here is exactly that the timeout (of zero) is exceeded
because as you increase capability in the middlebox, the timeout delay
would increase proportionally. 

So this isn't a perfect message, but it does have a correct
interpretation and it wouldn't affect non-fragment packets. 

Creating a separate "frag not supported" would basically be saying "I
don't support existing requirements", and I don't think we should codify
that with a separate ICMP. 

> I would be glad to work with you on this project, but I think that it is out 
> of scope for the current draft. (This draft is a BCP that comments on the 
> current state of IP fragmentation. It has no business defining new ICMP 
> messages.) 
> 
> Can we address the new message in a separate draft? 
> 
> Ron 
> 
> FROM: Joe Touch  
> SENT: Wednesday, November 14, 2018 3:29 PM
> TO: Ron Bonica 
> CC: Tom Herbert ; int-area 
> SUBJECT: Re: [Int-area] Stateless devices and IP fragmentation 
> 
> On 2018-11-14 11:35, Ron Bonica wrote:
> 
>> Folks,
>> 
>> Since we seem to have reached consensus on Section 7.1, let's take another 
>> stab at Section 7.3. I am looking particularly to Tom Herbert and Joe Touch 
>> for feedback, since they objected to the previous formulation.
>> 
>> Proposed text follows
>> 
>> Ron
>> 
>> 7.3.  For Middle Box Developers
>> 
>> 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.
> 
> I'd encourage a sentence here that indicates the conditions under which the 
> SHOULD can be relaxed or not, i.e., they really MUST but when they cannot 
> they need to be less silent about failure or something... (foreshadowing the 
> last paragraph below). 
> 
>> Price and performance considerations frequently motivate network operators 
>> to deploy stateless middle boxes. These stateless middle boxes may perform 
>> sub-optimally or process IP fragments in a manner that is not compliant with 
>> RFC 791 or RFC 8200. Providers of such middle boxes MUST document product's 
>> their behavior.
> 
> IMO, they really ought to also MUST default to at least occasionally sending 
> frag reassembly timeouts if fragments are consistently dropped. 
> 
>> For example, a network operator may be motivated to deploy a stateless load 
>> balancer. Because the load balancer is stateless, it is likely to exhibit on 
>> of the following behaviors:
>> 
>> - For all packets, implement a load balancing algorithm whose inputs are 
>> drawn from the IP header. This algorithm facilitates RFC compliant behavior. 
>> However,  it may distribute load unevenly.
>> 
>> - For fragmented packets, implement a load balancing algorithm whose inputs 
>> are drawn from the IP header. For non-fragmented packets, implement a load 
>> balancing algorithm whose inputs are drawn from the IP header and the Layer 
>> 4 header.  This algorithm facilitates RFC compliant behavior. It also 
>> improves load distribution for flows that do not included fragmented 
>> packets. However, if a flow contains fragmented packets, packets belonging 
>> to that flow can be distributed between two different outgoing interfaces.
>> 
>> - For all packets, implement a load balancing algorithm whose inputs are 
>> drawn from the IP header and the Layer 4 header. Discard all IP fragments. 
>> This algorithm does not facilitate RFC compliant behavior and can cause 
>> black holes.
>> 
>> All of the above-mentioned behaviors are sub-optimal. However, one behavior 
>> may be acceptable to one network operator while another behavior is 
>> acceptable to another network operator. Middle box vendors MUST provide 
>> network operators with all of the information required to  make intelligent 
>> middle box deployment decisions.
> 
> As above, I hope we can also add "at least occasionally send an ICMP". 
> However, the discussion above focuses on load balancing, which has a 
>

Re: [Int-area] Stateless devices and IP fragmentation

[Joe Touch]

On 2018-11-14 13:25, Brian E Carpenter wrote:

> ...
> 
> Trying to use the traditional 5-tuple will not work well with
> fragments.
> 
> It's more complicated at the server farm end.
> "Moreover, the transport-layer
> information such as the source port is not repeated in fragments,
> which generally prevents stateless load balancers from supporting
> fragmented traffic since they generally cannot reassemble
> fragments."  [RFC7098].
> 
> Brian

That seems overstated. A stateless load balancer can always have a
default, in which case it could easily support fragments - though less
efficiently than intended. 

The problem lies with NATs, for which a default cannot exist. 

Joe___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area