RE: Last Call: <draft-ietf-6man-oversized-header-chain-08.txt> (Implications of Oversized IPv6 Header Chains) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Fernando,

I want to revisit a point that needs to be corrected:

> The point is that this is no worse than IPv4.

Why should it be as bad as IPv4 when it can be better? IPv4
middleboxes that wish to do deep packet inspection may need to
gather the fragments of a fragmented datagram before deciding
whether to let them pass through. IPv6 middleboxes shouldn't
have to do that, but they will if the host is permitted to
include MTU-sized header chains and there is a tunnel on the
path that has to fragment for whatever reason.

> And it is very likely
> that one of underlying encapsulations will be IPv4.

That is not necessarily true. Tunnels are used for many reasons
other than IPv6/IPv4 transition, including routing control,
mobility, traffic engineering, multihoming, security etc.
Tunnels will be part of the IPv6 architecture long after IPv4
has faded into the sunset, so let's get this right now so we
don't have to live with legacy behavior.

Thanks - Fred
fred.l.templin@xxxxxxxxxx







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]