On 2018-11-14 12:35, Ole Troan wrote:

> Joe,
> 
> For IPv4 part of the transport headers are now part of the network layer. 
> Forwarding is done one address and port.
> I.e it's now part of 'normal' routing/forwarding. That's absolutely not the 
> case. In IPv6 packets are delivered to hosts based on longest match on 
> destination addresses, while for IPv4 it's a match IPv4 DA and DP. For ECMP, 
> this is never an issue. ECMP can easily use a default for fragments and move 
> on with life.

I am not sure why you bring in ECMP. 

Most of Ron's text is based on load balancing - which is composed of two
cases: ECMP and end server. 

> (It is actually a problem for ECMP, since fragmented and non-fragmented 
> packets are prone to take different routes, but that seems to be far off 
> topic).

That can't be any more a problem than different ports taking different
routes. 

>> For end-system load balancing, similar defaults can work, but it's also 
>> reasonable to expect that a device that acts on behalf of an end system that 
>> way should do the work of an end system to reassemble.
>> 
>> For DPI, reassembly - and sometimes restoration of the TCP data stream 
>> across segments - is necessary anyway.
>> 
>> For NAT, virtual reassembly is necessary.
> 
> If the packet doesn't isn't TCP or UDP and the ports are available any IPv4 
> packet will have a significantly higher drop probability.

There's a big difference between "higher" and "100%". The former is
always OK, the latter is not, at least it should not be silent. 

> I'm fine with you not accepting that. 
> 
>> None of these are specific to IPv4; even in IPv6, flow IDs are not a magic 
>> solution -- they need similar fragmentation support.
> 
> Of course they are. One is IETF mandated and required to be able to forward 
> packets, the other is not.

Both IPv4 and IPv6 are IETF mandated. Both require support for source
fragmentation both at the endpoints and in forwarding. 

Joe 

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

Reply via email to