Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

["Templin, Fred L" <[e-mail]>]

This report is troubling to me. One of the unspoken tenets of
IPv6 is that it fixes fragmentation and reassembly, for example
by including a large-enough Identification field to avoid wrapping
issues at high data rates (see RFC4963). With this knowledge, a
reasonable response from a host that receives a Packet Too Big
message may be to begin fragmenting large packets (up to 1500
bytes) rather than reduce the size of the packets it sends.

If a stateful middlebox needs to inspect all fragments before
forwarding to the final destination, then it should do something
like Virtual Fragmentation and Reassembly and then pass the
fragments through to the final destination assuming filtering
rules are satisfied. Either that, or simply allow non-initial
fragments through and let the final destination take the
appropriate actions. The choice may be dependent on whether the
middlebox is located closer to the core or closer to the edge.

Taking away IPv6 fragmentation/reassembly removes an important
option that should be available to end systems. It would further
"dumb-down" the eventual deployment of IPv6 we would see, and
would make dealing with MTU diversity that much harder.

Thanks - Fred
[e-mail]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Tuesday, October 16, 2012 5:45 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [v6ops] new draft: draft-taylor-v6ops-fragdrop
> 
> 
> A new draft has been posted, at http://tools.ietf.org/html/draft-taylor-
> v6ops-fragdrop. Please take a look at it and comment.
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops