Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
> On Aug 2, 2018, at 1:06 PM, Ole Troan wrote: > > Joe, > > >> I am not ignoring them; I'm claiming that they all have the same >> inherent deployment and implementation limitations. >> >> Just because operators/vendors "want" to do otherwise does not make it >> possible. > > There was IETF consensus behind those documents (A+P). You mean the *experimental* RFCs that describe an approach that doesn't update RFC791? (i.e., RFC6364?) Or something else? >>> >>> The protocol specifications of A+P are all standards track. >>> RFC7596, RFC7597, RFC7599. >>> >> Thanks for the refs. Note that none of those update RFCs 791 or 1122, so if >> frag breaks them, then it's their error. > > I wouldn’t be surprised if there were disagreements about that interpretation > of “updates”. That’s not how it works, any more than there are disagreements over “standards track”. Those docs are either compatible with existing specs, update those specs, or are in error. RFC791 takes precedence, having come earlier - until it is overridden by an update. > >> It also looks like (at first glance at least) these devices work only when >> there isn't multipath between the back and front side. > > The A+P routers are stateless and do support multipath. Including traffic > does not need to be symmetric. > That’s the main selling point for A+P, that you don’t need per flow state in > the core of the network. The +P part doesn’t seem like it’s compatible with fragmentation, though - yet it doesn’t update RFC791 to deprecate it throughout the Internet. The only conclusion is that A+P should never be deployed in the presence of fragmentation - not that it should drop fragments, nor that we should consider deprecating fragmentation to address that flaw. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
Joe, > I am not ignoring them; I'm claiming that they all have the same inherent > deployment and implementation limitations. > > Just because operators/vendors "want" to do otherwise does not make it > possible. There was IETF consensus behind those documents (A+P). >>> >>> You mean the *experimental* RFCs that describe an approach that doesn't >>> update RFC791? (i.e., RFC6364?) Or something else? >> >> The protocol specifications of A+P are all standards track. >> RFC7596, RFC7597, RFC7599. >> > Thanks for the refs. Note that none of those update RFCs 791 or 1122, so if > frag breaks them, then it's their error. I wouldn’t be surprised if there were disagreements about that interpretation of “updates”. > It also looks like (at first glance at least) these devices work only when > there isn't multipath between the back and front side. The A+P routers are stateless and do support multipath. Including traffic does not need to be symmetric. That’s the main selling point for A+P, that you don’t need per flow state in the core of the network. Cheers, Ole ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
On 2018-08-02 12:33, Ole Troan wrote: > Joe, > > I am not ignoring them; I'm claiming that they all have the same inherent > deployment and implementation limitations. > > Just because operators/vendors "want" to do otherwise does not make it > possible. > There was IETF consensus behind those documents (A+P). You mean the *experimental* RFCs that describe an approach that doesn't update RFC791? (i.e., RFC6364?) Or something else? The protocol specifications of A+P are all standards track. RFC7596, RFC7597, RFC7599. Thanks for the refs. Note that none of those update RFCs 791 or 1122, so if frag breaks them, then it's their error. It also looks like (at first glance at least) these devices work only when there isn't multipath between the back and front side. Joe___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
Joe, >>> I am not ignoring them; I'm claiming that they all have the same inherent >>> deployment and implementation limitations. >>> >>> Just because operators/vendors "want" to do otherwise does not make it >>> possible. >> >> There was IETF consensus behind those documents (A+P). > > You mean the *experimental* RFCs that describe an approach that doesn't > update RFC791? (i.e., RFC6364?) Or something else? The protocol specifications of A+P are all standards track. RFC7596, RFC7597, RFC7599. >> In the _new_ IPv4 Internet architecture the IPv4 header looks like this: >> >> 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 >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>|.0x45 |Type of Service| Total Length | >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>| Identification|Flags| Fragment Offset| >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>| Time to Live | 6|17 | Header Checksum | >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>| Source Address | >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>|Destination Address| >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>| Source Port | Destination Port | >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> If the the ascii art comes through. >> > A+P didn't update 791. There is no *new* IP header. > > The diagram above is a combination of IP - without options, notably - and > only two specific transports. It isn't an IPsec'd packet, a tunneled packet, > or any other transport. The Internet is not merely TCP and UDP over IP with > no options. For the public IPv4 Internet it is. (Sure there is some support for ICMP as well). >> In contrast to NAT the address and port fields are not rewritten. Only used >> for forwarding. > > And there may be limits to where that kind of approach can be deployed. The > jury is still out - this is experimental. There’s plenty of room for architectural purity in IPv6. Unfortunately there isn’t that luxury in IPv4 any more. Ole ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
On 2018-08-02 08:38, Ole Troan wrote: > Joe, > >> I am not ignoring them; I'm claiming that they all have the same inherent >> deployment and implementation limitations. >> >> Just because operators/vendors "want" to do otherwise does not make it >> possible. > > There was IETF consensus behind those documents (A+P). You mean the *experimental* RFCs that describe an approach that doesn't update RFC791? (i.e., RFC6364?) Or something else? > In the _new_ IPv4 Internet architecture the IPv4 header looks like this: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |.0x45 |Type of Service| Total Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identification|Flags| Fragment Offset| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Time to Live | 6|17 | Header Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Destination Address| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Port | Destination Port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > If the the ascii art comes through. A+P didn't update 791. There is no *new* IP header. The diagram above is a combination of IP - without options, notably - and only two specific transports. It isn't an IPsec'd packet, a tunneled packet, or any other transport. The Internet is not merely TCP and UDP over IP with no options. > In contrast to NAT the address and port fields are not rewritten. Only used > for forwarding. And there may be limits to where that kind of approach can be deployed. The jury is still out - this is experimental. Joe___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
On Aug 2, 2018, at 10:07 AM, Tom Herbert wrote: >> Applications need to work when faced with adverse conditions. They can work >> less well, that's fine, but they still need to work. >> > This leads to driving everything down to only support the least common > denominator. Problem is that we can never move things forward if > everyone is bound to LCD. > > Tom Yup. As I said, we then need to reinvent the Internet over port 443. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
On Thu, Aug 2, 2018 at 8:50 AM, Mikael Abrahamsson wrote: > On Thu, 2 Aug 2018, Joe Touch wrote: > >> So you want us to redesign the Internet to run over port 443. > > > Nope. > >> The again, IP has fragmentation. That too is reality, even if we don’t >> like it. > > > IP have lots of things. Hop-by-hop-headers for instance. Really bad idea. > Mikael, Definition of hop-by-hop options might have been flawed in that they were required to be processed by every node in the path. But with that restriction relaxed, this now is the only feasible mechanism that provides inband host to network or network to host signaling. IMO, this is far better idea than all the approaches that have being do ad hoc DPI into transport layers or even transport payload. Fortunately this is one area that might progress. QUIC seems to have enough traction and encrypts header to render DPI ineffective. If the QUIC application wants to tell something to the network it can do that by HBH (this is a premise of FAST). >> Again, something broken needs fixing. You can chase the symptoms forever >> or you can deal with the cause. It’s simply not tenable to ‘fix’ the >> internet to accommodate broken devices. > > > The thing here is that you haven't proposed a realistic way to deal with the > problem. We do not have any enforcement mechanism. > > Applications need to work when faced with adverse conditions. They can work > less well, that's fine, but they still need to work. > This leads to driving everything down to only support the least common denominator. Problem is that we can never move things forward if everyone is bound to LCD. Tom > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > > ___ > 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] WG Adoption Call: IP Fragmentation Considered Fragile
On Thu, 2 Aug 2018, Joe Touch wrote: So you want us to redesign the Internet to run over port 443. Nope. The again, IP has fragmentation. That too is reality, even if we don’t like it. IP have lots of things. Hop-by-hop-headers for instance. Really bad idea. Again, something broken needs fixing. You can chase the symptoms forever or you can deal with the cause. It’s simply not tenable to ‘fix’ the internet to accommodate broken devices. The thing here is that you haven't proposed a realistic way to deal with the problem. We do not have any enforcement mechanism. Applications need to work when faced with adverse conditions. They can work less well, that's fine, but they still need to work. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
Joe, > I am not ignoring them; I’m claiming that they all have the same inherent > deployment and implementation limitations. > > Just because operators/vendors “want” to do otherwise does not make it > possible. There was IETF consensus behind those documents (A+P). In the _new_ IPv4 Internet architecture the IPv4 header looks like this: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |.0x45 |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification|Flags| Fragment Offset| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | 6|17 | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Destination Address| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the the ascii art comes through. In contrast to NAT the address and port fields are not rewritten. Only used for forwarding. The source port and destination port fields are shared between L3 and L4. With an out-of-band provisioning protocol informing the end system which ports are available for applications. Ole___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
> On Aug 2, 2018, at 8:02 AM, Mikael Abrahamsson wrote: > >> On Thu, 2 Aug 2018, Joe Touch wrote: >> >> Just because operators/vendors “want” to do otherwise does not make it >> possible. > > I've been on hotel wifis that are behind 3 layers of NAT, PMTUD non-working, > PMTU is like 1450, and the only thing saving the day is TCP MSS adjust, so > the only thing that works is something over TCP or that happens to use small > enough packets. I have been on other networks where basically only thing that > works is 80/443 and some mail related ports. Complaining doesn't help, > because peoples mobile phones work ok. > > It's "possible", because it works well enough for what some people use it > for. Very few complain, so there is no improvement. > > So while you're technically and formally right, there is no enforcement and > the only thing we can do is write requirements, tests, educate, but also > educate application and protocol developers on what they might face in the > real world. This is engineering, not physics. Real world is more important > than map. > > IP-fragmentation has always been fragile, and it's not improving. The > Internet is growing, so this is not getting better. This is reality, even > though we do not like it. So you want us to redesign the Internet to run over port 443. As you said, “this is reality, even if we don’t like it”. The again, IP has fragmentation. That too is reality, even if we don’t like it. Again, something broken needs fixing. You can chase the symptoms forever or you can deal with the cause. It’s simply not tenable to ‘fix’ the internet to accommodate broken devices. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
On Thu, 2 Aug 2018, Joe Touch wrote: Just because operators/vendors “want” to do otherwise does not make it possible. I've been on hotel wifis that are behind 3 layers of NAT, PMTUD non-working, PMTU is like 1450, and the only thing saving the day is TCP MSS adjust, so the only thing that works is something over TCP or that happens to use small enough packets. I have been on other networks where basically only thing that works is 80/443 and some mail related ports. Complaining doesn't help, because peoples mobile phones work ok. It's "possible", because it works well enough for what some people use it for. Very few complain, so there is no improvement. So while you're technically and formally right, there is no enforcement and the only thing we can do is write requirements, tests, educate, but also educate application and protocol developers on what they might face in the real world. This is engineering, not physics. Real world is more important than map. IP-fragmentation has always been fragile, and it's not improving. The Internet is growing, so this is not getting better. This is reality, even though we do not like it. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
