On 6/24/13 12:19 PM, Marc Lampo wrote:
-1
Not because I'm a fan of fragmentation, but I think a layer 3 (IP)
protocol that does not support fragmentation should really be a *new*
IP version.
In my opinion, the changes are too dramatic :
if layer 3, not supporting fragmentation, is asked to sent a message,
too big for one packet,
it should inform layer 4 with an error message;
while a layer 3 that supports fragmentation, can fragment and send in
multiple packets (and return succes to layer 4).
imho in some respects this is simply closing the circle...
Intermediate hopes can't fragment in ipv6 leaving it the exclusive
domain of endpoints. if the endpoints can't simply generate large
datagrams at the ip layer then they have to fragment upper layer
datagrams somewhere else.
I agree with Fred T that this is a particular problem with tunnels
becuase the IP datagrams you're encapsulating will have to be fragmented
in some fashion, alternatively you really have to be able to rely on
PMTUD work and frankly I'd really like to work becuase I think it's
rather sad that MTUs <= 1500 are all we can expect to support end-to-end.
I can imagine case exist - without searching for explicit examples,
some already given or hinted at by others in this discussion -
where two partners in a conversation cannot communicate (perhaps only
simplex ?) because one is implemented
on a host that implements IPv6 with fragmentation and the other on a
host that implements IPv6 without fragmentation.
I do agree that fragmentation introduces attack vectors,
but allowing that hosts do not implement it is, for me, not the
correct approach.
I'd prefer to insist that all headers, up till and including the layer
4, are in the first fragment
and that implementations provide correct implementation of fragmentation.
(both suggestions merely a repetition of other contributors in this
discussion)
In one of the replies you, Ron, write :
> I don't know of a study. However, this is probably a safe assumption
considering that:
>
> - many TCP implementation leverage PMTUD
> - many enterprise block fragments
> - many firewalls, by default, block IPv6 fragments
I cannot comment on the first point.
My experience with enterprises is that firewalls used normally cope
well with fragments
(in the sense that they can flow through)
((perhaps in the old days, before "stateful inspection", with basic
ACL's;
but even a cheap home router copes with (IPv4) fragmentation))
As for point 3 : when I look at firewall capabilities concerning IPv6
I actually look if it is possible to allow *only* the fragmentation
extension header
(as, in my opinion, it is the only extension header needed to let the
business run)
((a statement that, by itself, might generate discussion - please, in
a different thread))
So, as for the list of 3 points, I cannot support this "safe assumption".
Kind regards,
Marc
On Thu, Jun 20, 2013 at 5:55 PM, Ronald Bonica <rbon...@juniper.net
<mailto:rbon...@juniper.net>> wrote:
Folks,
Please review this draft and provide comments.
Ron
> -----Original Message-----
> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
[mailto:internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>]
> Sent: Thursday, June 20, 2013 11:48 AM
> To: Ronald Bonica
> Subject: New Version Notification for
draft-bonica-6man-frag-deprecate-
> 00.txt
>
>
> A new version of I-D, draft-bonica-6man-frag-deprecate-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
>
> Filename: draft-bonica-6man-frag-deprecate
> Revision: 00
> Title: IPv6 Fragment Header Deprecated
> Creation date: 2013-06-20
> Group: Individual Submission
> Number of pages: 7
> URL: http://www.ietf.org/internet-drafts/draft-bonica-6man-
> frag-deprecate-00.txt
> Status: http://datatracker.ietf.org/doc/draft-bonica-6man-
> frag-deprecate
> Htmlized: http://tools.ietf.org/html/draft-bonica-6man-frag-
> deprecate-00
>
>
> Abstract:
> This memo deprecates the IPv6 Fragment Header. It provides
reasons
> for deprecation and updates RFC 2460.
>
>
>
>
>
> The IETF Secretariat
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org <mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
