Subject: RE: draft-bonica-6man-frag-deprecate

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 1 Jul 2013 15:59:46 +0000

Hi Ole,

> -----Original Message-----
> From: Ole Troan [mailto:[email-masked]]
> Sent: Friday, June 28, 2013 11:56 PM
> To: Templin, Fred L
> Cc: Brian E Carpenter; 6man
> Subject: Re: draft-bonica-6man-frag-deprecate
> 
> Fred,
> 
> >> in my understanding the 1280 minimum MTU for IPv6 was already chosen
> to
> >> accommodate nested tunnels.
> >
> > Right, but..
> >
> >> the expectation made, I believe, was that native links support at
> least
> >> an MTU of 1500 bytes,
> >
> > But, that expectation went out the window at the same time the IPv6
> > minMTU was set to 1280 - so now 1280 is all that can be expected.
> 
> quite the opposite.
> physical link MTUs aren't getting smaller.
> do you have any evidence that operators set the IPv6 MTU to a value
> smaller than the MTU supported
> by the link-layer?

The evidence is in RFC2460, where the minMTU is set to 1280.
Plus, there are links (e.g., 6lowpan, aviation data links,
tactical military links etc.) where setting an MTU larger
than 1280 might not be practical.
 
> as far as I can see the setting IPv6 minimum MTU to 1280, which gives
> ample room for
> nested tunnels works as designed.

But, what would that look like in real life? The first tunnel
(T1) would have to set a 1280 MTU so that its tunneled packets
would emerge as 1320 bytes. Then, the next tunnel (T2) would
have to set a 1320 MTU so its tunneled packets would emerge as
1360. Then the next tunnel (T3) would have to set a 1360 MTU
so that its tunneled packets would emerge as 1400, etc. until
we run out of available MTU. The question is, how can those
tunnels be so carefully coordinated so that the nesting is
nailed down enough so that we will never have an MTU infraction?
In a single administrative domain where an operator can lay
hands on every tunnel ingress this may be possible, but we
need to engineer for the general case.

> > So, without fragmentation, when the tunnel ingress receives a 1280
> > packet, it emits a (1280+HLEN) packet. If that packet is dropped
> > at a link that configures a 1280 MTU, then it simply black holes.
> >
> >> allowing 220 bytes for tunnel encap (5 IPv6 headers).
> >
> > Tunnels within tunnels presents an additional pain point, but the
> > plain truth is that IPv6 links only need to configure a 1280 MTU;
> > not a 1500.
> 
> again, why would anyone do that?

Performance. What matters is time on the wire, and some "wires"
may not be fast enough to support anything larger than 1280
(see above).

> the pain here is fragmentation, not supporting an MTU larger than 1280.

Fragmentation and reassembly is a pain point for some (but
not all) routers. The pain may be observed by the hosts
which would (selfishly) like to do something to improve
their performance. With SEAL, to get better performance (and
in the process ease the burden on the routers) the hosts can
use RFC4821 and begin sending packets larger than 1500. 
 
> >> you want to avoid reassembly at tunnel endpoints, if you care about
> >> performance that is.
> >
> > Unfortunately, reassembly is absolutely necessary if the tunnel is
> > configured over a path that contains at least one 1280 link (see
> above).
> 
> reassembly in the network is a non-starter.

Let me say again what I said several messages ago. Never say
"always" and never say "never". The answer as to whether
reassembly can be tolerated is: "it depends" (i.e., it
depends on where the tunnel endpoints are positioned). 

> the vendor I'm most familiar with does not do this in hardware. sure,
> you can get reassembly, but at an order of one or two magnitudes less.
> if anyone know of platforms doing IPv6 fragment reassembly at line rate
> for 10G or 100G interfaces I'll stand corrected. ;-)
> for now reassembly in the network is not realistic.

Reassembly is required by RFC2460, RFC2473 and I think others
have also been mentioned. To support tunnels, and especially
tunnels within tunnels, it needs to be there.

Thanks - Fred
[email-masked]

> cheers,
> Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 1 Jul 2013 16:06:44 +0000

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, June 28, 2013 9:20 PM
> To: Templin, Fred L
> Cc: james woodyatt; 6man
> Subject: Re: New Version Notification for draft-bonica-6man-frag-
> deprecate-00.txt
> 
> On one point...
> 
> 
> On 29/06/2013 10:44, Templin, Fred L wrote:
> ...
> >> and (b) accepting that strapping the MTU at 1280 is
> >> a reasonable short term policy. If (a) progressively pervades
> >> the installed base then (b) can be dropped as the years go by.
> >
> > Once a link sets a 1280 MTU, how will it know that it is now
> > safe to increase the MTU? And, once set, how can we expect
> > operators to go back and re-set in the future. IMHO, strapping
> > the MTU to 1280 everywhere now would become ossified long into
> > the future.
> 
> It would certainly take years, but I think the end result would be
> implementors raising the default to the real link MTU, one stack
> at a time. I don't think you find many IPv4 stacks today with
> the MTU set low by default.

The transition anticipated by SEAL is as follows. Packets that
are no larger than 1500 bytes are unconditionally accommodated
with fragmentation/reassembly used if necessary. Hosts will then
notice that they can get better performance by sending packets
that are larger than 1500, and will use RFC4821 to ensure that
those larger packets are getting through. The Internet will then
naturally gravitate toward larger packets, and eventually the
Internet "cell size" will bump up from 1500 to 8KB.

Thanks - Fred

>     Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 1 Jul 2013 16:14:37 +0000

FYI, from a historical perspective here is the origin of the
1280 minMTU:

Thanks - Fred

---

List:       ipng
Subject:    (IPng 4802) increasing the IPv6 minimum MTU
From:       Steve Deering <deering () cisco ! com>
Date:       1997-11-14 0:37:00
[Download message RAW]

In the ipngwg meeting in Munich, I proposed increasing the IPv6 minimum MTU
from 576 bytes to something closer to the Ethernet MTU of 1500 bytes, (i.e.,
1500 minus room for a couple layers of encapsulating headers, so that min-
MTU-size packets that are tunneled across 1500-byte-MTU paths won't be
subject to fragmentation/reassembly on ingress/egress from the tunnels,
in most cases).

After the short discussion in the Munich meeting, I called for a show of
hands, and of those who raised their hands (about half the attendees, if
I recall correctly), the vast majority were in favor of this change --
there were only two or three people opposed.  However, we recognized that
a fundamental change of this nature requires thoughtful discussion and
analysis on the mailing list, to allow those who were not at the meeting
and those who were there but who have since had second thoughts, to express
their opinions.  A couple of people have already, in private conversation,
raised some concerns that were not identified in the discussion at the
meeting, which I report below.  We would like to get this issue settled as
soon as possible, since this is the only thing holding up the publication
of the updated Proposed Standard IPv6 spec (the version we expect to advance
to Draft Standard), so let's see if we can come to a decision before the ID
deadline at the end of next week (hoping there isn't any conflict between
"thoughtful analysis" and "let's decide quickly" :-).

The reason I would like to increase the minimum MTU is that there are some
applications for which Path MTU Discovery just won't work very well, and
which will therefore limit themselves to sending packets no larger than
the minimum MTU.  Increasing the minimum MTU would improve the bandwidth
efficiency, i.e., reduce the header overhead (ratio of header bytes to
payload bytes), for those applications.  Some examples of such applications
are:

    (1) Large-fanout, high-volume multicast apps, such as multicast video
	("Internet TV"), multicast netnews, and multicast software
	distribution.  I believe these applications will end up limiting
	themselves to packets no large than the min MTU in order to avoid
	the danger of incurring  an "implosion" of ICMP Packet-Too-Big
	messages in response.  Even though we have specified that router
	implementations must carefully rate-limit the emission of ICMP
	error messages, I am nervous about how well this will work in
	practice, especially once there is a lot of high-speed, bulk
	multicasting happening.  An appropriate choice of rate or
	probability of emission of Packet-Too-Big responses to multicasts
	really depends on the fan-out of the multicast trees and the MTUs of
	all the branches in that tree, which is unknown and unknowable to
	the routers.  Being sensibly conservative by choosing a very low
	rate could, in many cases, significantly increase the delay before
	the multicast source learns the right MTU for the tree and, hence,
	before receivers on smaller-MTU branches can start receiving the
	data.

    (2) DNS servers, or other similar apps that have the requirement of
	sending a small amount of data (a few packets at most) to a very
	large and transient set of clients.  Such servers often reside on
	links, such as Ethernet, that have an MTU bigger than the links on
	which many of their clients may reside, such as dial-up links.  If
	those servers were to send many reply messages of the size of their
	own links (as required by PMTU Discovery), they could incur very
	many ICMP packet-too-big messages and consequent retransmissions of
	the replies -- in the worse case, multiplying the total bandwidth
	consumption (and delivery delay) by 2 or 3 times that of the
	alternative approach of just using the min MTU always.  Furthermore,
	the use of PMTU Discovery could result in such servers filling up
	lots of memory withed cached PMTU information that will never be
	used again (at least, not before it gets garbage-collected).

The number I propose for the new minimum MTU is 1280 bytes (1024 + 256,
as compared to the classic 576 value which is 512 + 64).  That would
leave generous room for encapsulating/tunnel headers within the Ethernet
MTU of 1500, e.g., enough for two layers of secure tunneling including
both ESP and AUTH headers.

For medium-to-high speed links, this change would reduce the IPv6 header
overhead for min MTU packets from 7% to 3% (a little less than the IPv4
header overhead for 576-byte IPv4 packets).  For low-speed links such as
analog dial-up or low-speed wireless, I assume that header compression will
be employed, which compresses out the IPv6 header completely, so the IPv6
header overhead on such links is effectively zero in any case.

Here is a list of *disadvantages* to increasing the IPv6 minimum MTU that
have been raised, either publically or privately:

    (1) This change would require the specification of link-specific
	fragmentation and reassembly protocols for those link-layers
	that can support 576-byte packets but not 1280-byte packets,
	e.g., AppleTalk.  I think such a protocol could be very simple,
	and I briefly sketch such a protocol in Appendix I of this
	message, as an example.

	Often, those links that have a small native MTU are also the ones
	that have low bandwidth.  On low-bandwidth links, it is often
	desirable to locally fragment and reassemble IPv6 packets anyway
	(even 576-byte ones) in order to avoid having small, interactive
	packets (e.g., keystrokes, character echoes, or voice samples)
	be delayed excessively behind bigger packets (e.g., file transfers);
	the small packets can be interleaved with the fragments of the
	big packets.  Someone mentioned in the meeting in Munich that the
	ISSLL WG was working on a PPP-specific fragmentation and
	reassembly protocol for precisely this reason, so maybe the job
	of specifying such a protocol is already being taken care of.

    (2) Someone raised the concern that, if we make the minimum MTU close
	to Ethernet size, implementors might never bother to implement PMTU
	Discovery.  That would be regrettable, especially if the Internet
	evolves to much more widespread use of links with MTUs bigger
	than Ethernet's, since IPv6 would then fail to take advantage of
	the bandwidth efficiencies possible on larger MTU paths.

    (3) Peter Curran pointed out to me that using a larger minimum MTU for
	IPv6 may result in much greater reliance on *IPv4* fragmentation and
	reassembly during the transition phase while much of the IPv6
	traffic is being tunneled over IPv4.  This could incur unfortunate
	performance penalties for tunneled IPv6 traffic (disasterous
	penalties if there is non-negligible loss of IPv4 fragments).
	I have included Peter's message, describing his concern in more
	detail, in Appendix II of this message.

    (4) Someone expressed the opinion that the requirement for link-layer
	fragmentation and reassembly of IPv6 over low-cost, low-MTU links
	like Firewire, would doom the potential use of IPv6 in cheap
	consumer devices in which minimizing code size is important --
	implementors of cheap Firewire devices would choose IPv4 instead,
	since it would not need a fragmenting "shim" layer.  This may well
	be true, though I suspect the code required for local frag/reasm
	would be negligible compared to the code required for Neighbor
	Discovery.

Personally, I am not convinced by the above concerns that increasing the
minimum MTU would be a mistake, but I'd like to hear what the rest of the
WG thinks.  Are there other problems that anyone can think of?  As I
mentioned earlier, the clear consensus of the Munich attendees was to
increase the minimum MTU, so we need to find out if these newly-identified
problems are enough to swing the consensus in the other direction.  Your
feedback is heartily requested.

Steve

----------

Appendix I

Here is a sketch of a fragmentation and reassembly protocol (call it FRP)
to be employed between the IP layer and the link layer of a link with native
(or configured) MTU less than 1280 bytes.

Identify a Block Size, B, which is the lesser of (a) the native MTU of the
link or (b) a value related to the bandwidth of the link, chosen to bound
the latency that one block can impose on a subsequent block.  For example,
to stay within a latency of 200 ms on a 9600 bps link, choose a block size
of .2 * 9600 = 2400 bits = 240 bytes.

IPv6 packets of length <= B are transmitted directly on the link.
IPv6 packets of length > B are fragmented into blocks of size B
(the last block possibly being shorter than B), and those fragments
are transmitted on the link with an FRP header containing the following
fields:

	[packet ID, block number, end flag]

where:

	packet ID is the same for all fragments of the same packet,
	and is incremented for each new fragmented packet.  The size of
	the packet ID field limits how many packets can be in flight or
	interleaved on the link at any one time.

	block number identifies the blocks within a packet, starting at
	block zero.  The block number field must be large enough to
	identify 1280/B blocks.

	end flag is a one-bit flag which is used to mark the last block
	of a packet.

For example, on a 9600 bps serial link, one might use a block size of
240 bytes and an 8-bit FRP header of the following format:

	4-bit packet ID, which allows interleaving of up to 16 packets.
	3-bit block number, to identify blocks numbered 0 through 5.
	1-bit end flag.

On a 256 kpbs AppleTalk link, one might use the AppleTalk-imposed block
size of ~580 bytes and an 8-bit FRP header of the following format:

	5-bit packet ID, which allows for up to 32 fragmented packets in
		   flight from each source across the AppleTalk internet.
	2-bit block number, to identify blocks numbered 0 through 2.
	1-bit end flag.

On a multi-access link, like AppleTalk, the receiver uses the link-level
source address as well as the packet ID to identify blocks belonging to
the same packet.

If a receiver fails to receive all of the blocks of a packet by the time
the packet number wraps around, it discards the incompletely-reassembled
packet.  Taking this approach, no timers should be needed at the receiver
to detect fragment loss.  We expect the transport layer (e.g., TCP) checksum
at the final IPv6 destination to detect mis-assembly that might be caused by
extreme misordering/delay during transit across the link.

On links on which IPv6 header compression is being used, compression is
performed before fragmentation, and reassembly is done before decompression.

----------

Appendix II

From: Peter Curran <[email-masked]>
Subject: Re: IPv6 MTU issue
To: [email-masked] (Steve Deering)
Date: Mon, 22 Sep 1997 11:50:34 +0100 (BST)

Steve

My problem was that moving the MTU close to 1500 would have an adverse
effect on the transition strategy.  The current strategy assumes that the
typical Internet MTU is >576, and that sending an IPv6 packet close to the
minimum MTU will not require any IPv4 fragmentation to support the tunnel
transparently.  The PMTU discovery mechanism will 'tune' IPv6 to use a
suitable MTU.

If the IPv4 MTU is <= 576 then IPv4 fragmentation will be required to
provide a tunnel with a minimum MTU of 576 for IPv6.  This clearly places
a significant strain on the tunnelling nodes - as these will normally be
routers then there will be a demand for memory (for reassembly buffers)
as well as CPU (for the frag/reassembly process) that will have an overall
impact on performance.

This is an acceptable risk, as Internet MTU's of <= 576 are not too common.

However, if the minimum MTU of IPv6 is increased to something of the order
of 1200-1500 octets then the likelihood of finding an IPv4 path with an
MTU lower than this value increases (I think significantly) and this will
have a performance impact on these devices.

During the brief discussion of this matter in the IPNG session at Munich
you stated that MTU's less than 1500 where rare.  I don't agree with this
completely - it seems to be pretty common practise for smaller 2nd and 3rd
tier ISP's in the UK to use an MTU of 576 for connection to their transit
provider.  Their objective, I believe, is to 'normalize' the packet sizes
on relatively low bandwidth circuits (typically <1Mbps) to provide better
performance for interactive sessions compared to bulk-file transfer users.

I think that before we go ahead and make a decision on an increased minimum
MTU for IPv6 then we should discuss the issues a little more.

Incidentally, I am not convinced of the benefits of doing this anyway
(ignoring the issue raised above).  With a properly setup stack the PMTU
discovery mechanism seems to be able to select a good MTU for use on the
path - at least that is my experience on our test network and the 6Bone.

I appreciate that you are trying to address the issues of PMTU for multi-
casting but I don't see how raising the minumum MTU is going to help much.
PMTU discovery will still be required irrespective of the minimum MTU
adopted, unless we adopt a value that can be used on all link-layer technolo-
gies.

I would welcome wider discussion of these issues before pressing ahead
with a change.

Best regards

Peter Curran
TICL

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Mon, 01 Jul 2013 18:31:32 +0200 (CEST)

> nailed down enough so that we will never have an MTU infraction?

I strongly disagree that we should make provisions for umpteen levels
of tunneling. In my network, native IPv6 with no tunnels is clearly
the goal. Anything more than one level of tunneling is a *failure*.

I run my IPv6 customer links with MTU 1500.

> tunnels within tunnels, it needs to be there.

Reassembly is required by end systems, which typically don't run at
100G. 

If I were to vote with my wallet, reassembly at 100G and similar line
rates is *way* down on my requirements list. Requiring L4 info in the
first fragment (*and* in each subsequent fragment) is far more 
important.

Steinar Haug, AS 2116

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 1 Jul 2013 16:48:02 +0000

Hi Steinar,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 01, 2013 9:32 AM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]

Tunnels within tunnels are a fact of life in real networks today.
Tunnels are used for many things other than transition, including
security, mobility, routing control, etc. and deployment of IPv6
would sustain rather than reverse that trend. Plus, it is not just
about tunnels within tunnels but also native links that configure
a small MTU.

Back to tunnels within tunnels, there are *many* examples that
would prove my point but I will give just one. A mobile node
configures a 1280 MTU tunnel to a "home agent" and keeps the
tunnel alive as it moves around. A second mobile node comes
onto the link provided by the first mobile, and also configures
a 1280 MTU tunnel. The second mobile node emits a 1280 packet
which (when tunneled) becomes 1320. The first mobile node
drops the packet and returns "Packet Too Big". In response,
the second mobile has two choices: 1) fragment, or 2) shut
down the tunnel. 

> I run my IPv6 customer links with MTU 1500.

Good, but I would like to see you push that to 8KB.
 
> Reassembly is required by end systems, which typically don't run at

Reassembly is also required by any node that configures an
RFC2473 egress tunnel endpoint. 

> rates is *way* down on my requirements list.

Two things about this is that 1) the location of the tunnel
egress should be carefully selected, and 2) the SEAL tunnel
egress can use RFC4821-style probing to tune out fragmentation
when the path supports a sufficiently large MTU. SEAL is not
about steady-state, use-all-the-time fragmentation; it is
about doing what needs to be done while being as efficient
as possible.

> Requiring L4 info in the first fragment

SEAL does that.

> (*and* in each subsequent fragment)

SEAL doesn't do that unless some new IPv6 extension header was
defined. Then, SEAL would use the extension header the same as
any other IPv6 protocol.

> is far more important.

Good; let's make it happen.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 1 Jul 2013 19:43:52 +0000

Hi,

I would like to make one minor edit to what I have been saying:

> The Internet will then

I am not looking for a fixed "Internet cell size", and the 8KB
I mentioned was intended more as a near term goal rather than a
fixed size for the long term. What I am really looking for is an
Internet that can support "unlimited" MTUs (theoretical limit is
2^16 for IPv4 and 2^32 for IPv6).

Thanks - Fred

---

From: Francis Dupont <[email-masked]>
Date: Thu, 04 Jul 2013 13:11:01 +0200

In your previous mail you wrote:

>  Considering the above, I guess I'm in the camp of "avoid fragmentation
>  where possible". However, I don't think I'd go as far as deprecating it.

=> I have private notes about the deprecation of reassembly so
not so far... BTW there was (still is) a TCP/IP stack so poor it
doesn't handle reassembly of out of order TCP fragments, so the idea
is not so silly.

Regards

[email-masked]

---

From: Marc Lampo <[email-masked]>
Date: Fri, 5 Jul 2013 07:49:23 +0200

let's write a draft on deprecating the statement, from RFC 793, that

The TCP must recover from data that is ...
    delivered out of order by the internet communication system.

(my feeling :
 just like this would actually create a new, incompatible, transport
protocol;
 deprecating the fragmentation extension header creates a new, incompatible
to IPv6, network protocol)

Kind regards,

Marc

On Thu, Jul 4, 2013 at 1:11 PM, Francis Dupont <[email-masked]>wrote:

> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Fernando Gont <[email-masked]>
Date: Fri, 05 Jul 2013 15:16:00 +0200

> doesn't handle reassembly of out of order TCP fragments, so the idea

If you're going to deprecate something on the assumption that some
implementation does something stupid about it, then I wonder what we'd
be left with. -- for instance, you should be deprecating Neighbor
Discovery, because many implementations do things such as allowing the
NCE to consume all memory, not doing any sanity checks on the received
link-layer addresses, etc., etc.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Fri, 05 Jul 2013 16:59:32 +0200

On 06/30/2013 10:42 PM, C. M. Heard wrote:
> Fernando> So far (and without having read Ron's recent I-D -- shame on me), it
> Fernando> looks like the main two reasons for deprecating the fragmentation
> Fernando> function are:
> Fernando> 
> Fernando> 1) The inability of middle-boxes to parse past the first XXX bytes of a
> Fernando> packet
> Fernando> 
> Fernando> 2) Unavailability of the connection-id (five-tuple) in the non-first
> Fernando> fragments.
> 
> I disagree -- I think Mark Andrews got it (mostly) right in his message of Wed, 26 Jun 2013:
> 
> Mark> One needs to get the L4 information the firewall/loadbalancer uses in *each* fragment.

Do you have this in IPv4? -- No.

Then, why is it that special in v6?

> However, it won't help middle boxes that implement stateless packet filters.  Indeed, such 
> boxes have fundamental problems with non-first fragments irrespective of how many bytes of 
> extension headers they can parse or whether there are sufficient length limits on the extension 
> header chain that guarantee that the L4 header always appears in the first fragment.

If you want to do stateless filtering, you should focus on filtering the
first fragment. And have the end nodes (severs or whatever) implement
sensible garbage collection for queued fragments (as it's usually the case).

> As I see it, the biggest meta-issue in this discussionis for the IPv6 WG is to decide out whether 
> middle boxes that implement stateless packet filters with a "default-deny" policy will be a 
> significant part of the landscape indefinitely, regardless of what the IETF says about their 
> merits or lack thereof.

Again: Why is this more special in v6 than in v4?

-- You seem to be ignored the "questions" that I've asked.

Thanks,

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 5 Jul 2013 20:22:56 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fernando Gont

> link-layer addresses, etc., etc.

The more I read arguments pro and con, the less I think fragmentation should be deprecated.

Even in IPv4, fragmentation is always discouraged, but there are times when it comes in very handy. I'm honestly not sure why anything should be different, in this regard, with IPv6. The more differences IPv6 introduces, the more of a complete nuisance it becomes.

Bert

---

From: Mark Andrews <[email-masked]>
Date: Sat, 06 Jul 2013 12:05:56 +1000

In message <[email-masked]>, Fernando Gont writes:
> > Fernando> 1) The inability of middle-boxes to parse past the first XXX
> > Fernando>    bytes of a packet
> > Fernando> 
> > Fernando> 2) Unavailability of the connection-id (five-tuple) in the
> > Fernando>    non-first fragments.
> > 

It's not special in IPv6.  It is however easily *fixable* in IPv6
as the IPv6 packet format was designed to extended.  Additionally
IPv6 is the future and we are still very early into the lifetime
of IPv6.

If one wants to extend IPv4 to have similar capabilities go for it.
I just think doing so will be wasted effort but I'm not going to
stand in the way of someone that wants to do it.

> > However, it won't help middle boxes that implement stateless packet
> > filters.  Indeed, such boxes have fundamental problems with non-first
> > fragments irrespective of how many bytes of extension headers they can
> > parse or whether there are sufficient length limits on the extension

Which is what I do but it doesn't help with those that worry about
those non initial fragments filling pipes and reassembly queues to
the point where legitimate fragments that they want get discarded
too soon.

We need to be able to better classify non-initial fragments.  At
the moment we are classifying them to the L4 type (tcp, udp, icmp6,
ipv6, ipv4, etc.)

> > As I see it, the biggest meta-issue in this discussionis for the IPv6
> > WG is to decide out whether middle boxes that implement stateless packet
> > filters with a "default-deny" policy will be a  significant part of the
> > landscape indefinitely, regardless of what the IETF says about their
> > merits or lack thereof.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]