Subject: [v6ops] new draft: draft-generic-v6ops-tunmtu

From: <[email-masked]>
Date: Wed, 23 May 2012 05:45:01 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-generic-v6ops-tunmtu. Please take a look at it and comment.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 23 May 2012 07:21:56 -0700

Please review and comment on 'draft-generic-v6ops-tunmtu':

https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/

This new document takes the radical approach of proposing
IPv6 router fragmentation at the tunnel ingress so that
the tunnel MTU can be jacked up to 1500 bytes.

The document notes issues that arise when the IPv6 router
performs fragmentation - most notably, the selection of
the Identification value to place in the (router-inserted)
fragmentation header.

Please review and comment on this thread. Remember that
this approach is proposing something new and different
and should be discussed further on the list.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, May 23, 2012 5:45 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] new draft: draft-generic-v6ops-tunmtu
> 
> 
> A new draft has been posted, at http://tools.ietf.org/html/draft-generic-
> v6ops-tunmtu. Please take a look at it and comment.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Wed, 23 May 2012 07:48:08 -0700

> and should be discussed further on the list.

I will indeed comment in the thread. Generating discussion on the list, apart from the initial poke you saw this morning, is your responsibility. As we have been doing for a couple of years now, face time in Vancouver depends on list activity and interest.

---

From: Fred Baker <[email-masked]>
Date: Wed, 23 May 2012 09:48:43 -0700

On May 23, 2012, at 7:21 AM, Templin, Fred L wrote:
> Please review and comment on this thread. Remember that this approach is proposing something new and different and should be discussed further on the list.

A nit-pick point: I would prefer that the text didn't focus on "1500 byte MTUs" as much as simply allowing for larger PMTUs. For example, if I have an otherwise 9K-clean path but have a tunnel in it, I wouldn't want the tunnel to jack me up from a 1460 byte PMTU to a 1500 byte PMTU by sending slightly-too-large packets as packet pairs, one large and one small; I'd want a 9K-clean path, with small packet trains as long as they need to be. You'll notice "1460". I'm also not necessarily thinking about IPv6/IPv4 tunnels; I'm just as happy to think about IPv4/IPv6 tunnels or IPv6/IPv6 tunnels. I think you can address this comment with a sentence or two up front making the point clear, and then globally replacing references to tunnel types with the word "tunnel", and references to PMTUs having a given value to "PMTU".

As I understand it - quick read - you view an IPv6 end-to-end path as being from the addressed source to the addressed destination, and fragmentation/reassembly as being a process between the addressed source and destination. Hence, end to end fragmentation and reassembly as described in RFC 2460 could go from tunnel endpoint to tunnel endpoint.

A quick comment on the ident field issue. If you need a 32 bit number to take a given value at most once every 60 seconds, one implementation would be to have a clock that counts every 14 ns and use its value in the field (eg, 4294967296/60=71582788 distinct ident values per second). At the point where we have links for which even that isn't fast enough, putting multiple EIDs on the same source interface allows you to re-use the clock value. I could imagine other uses for the multiple-EID model; if I have an input-queued switch and as a result am doing the fragmentation on each of a number of ingress line cards that feed to a single egress line card, I could associate a different EID with each ingress card (as a source address) and give each a separate clock. That way I don't have to coordinate the packet streams. 

My understanding of the reason that the community has moved away from fragmentation in the network is the implied unreliability, the processing load, and the implications for the intermediate node's internal structure. 

The reliability issues comes to this. Take a look at
    ftp://ftpeng.cisco.com/fred/templin/LACNIC_Wednesday.pptx
which is a talk I gave at LACNIC a couple of weeks ago. Look specifically at slide 14. This is a very simple test that I actually did for a Networkers talk a decade back. The test setup is:

    +------+     +------+            +------+      +------+
    |Peer 1|     |Router+------------+Router|      |Peer 2|
    +--+---+     +--+---+            +--+---+      +--+---+
       |            |                   |             |
     --+------------+-----            --+-------------+-----

Peer 1 and 2 are PCs running some variant on unix, and the routers are 26xx series routers connected back to back at 2 MBPS. One could use any pair of link speeds one likes as long as one gets a dumbbell topology; the value of a relatively low link speed is that you don't have to generate a lot of traffic to get the effect. The effect is the some, however, regardless of link speed; it's just that numbers scale up and down accordingly.

On Peer 1, I place a file of a large enough size that it's going to take a while - maybe ten seconds - to move it to Peer 2 across the intervening link. On Peer 2, I open two windows. In one, I start a ping -s to Peer 1, and store the output in a file. This will run for the duration of the test. In the second window, I run a script. The script will:

     for N = 1..15
         open N parallel FTP sessions to GET N instances of the file from Peer 1
         wait until they all complete
         delete all of the resulting local files
         sleep for a couple of seconds
     end

Offline, I then do some number crunching on the "ping" durations. In sets of (IIRC) 11 numbers, I find the least (magenta), the greatest (yellow), the arithmetic mean (dark blue), and the standard deviation (light blue), and plot them.

So, in the graphic, going left to right, you see bumps of increasing height and width for one FTP session, two, three, four, ..., and on the right-most side the bump is for 15 FTPs in parallel. The maximum queue depth is Cisco's standard 40 buffers. An interesting implication: at the left side, a loss results in a TCP fast retransmit event, while on the right side, 40/15 < 3, so we have to assume that every loss (or at least many of them) results in a timeout/retransmission. With the pings, we have to assume we are getting a sampled measurement - losses only occur when there are more than 40 packets in the queue. Hence, I have to believe that the drop-off rate noticeable on the fourth through eleventh iterations are from slow start driving until there is a loss, and then some FTPs moving data a little more quickly than others, so that at the end of the iteration they don't all finish simultaneously.

The key thing I want to point out is this. Especially on the 11..15 iterations, the queue is at full occupancy most of the time. Hence, the points at which we see a tail drop are when Peer 1 sends multiple packets in a burst, and it is more likely to be the last packet in the burst that is dropped than the first. 

When we fragment packets in the network, we almost by definition get such bursts of traffic, meaning that we have an increased probability of dropping one of the fragments in a fragmented packet burst. That in turn has an embedded attack and creates an embedded point of vulnerability. If I am fragmenting packets but transferring them on a multi-path route, I can't say "oops, missed that fragment, toss all of the fragments I have assembled so far" as I can with PPP Multilink; I have to let them time out. So I now have a reassembly failure attack, and if someone wants to attack the infrastructure, spoofed source addresses allow him to at least consume buffer if not insert data into reassembled datagrams.

One of the key reasons that people have pushed back hard on fragmentation in the network is an observed decrease in reliability of the path.

The processing load is dependent on the structure of the implementation. In any event, doing something is more of a processing load than not doing it, so by definition fragmentation and reassembly increase processing load. Now, how does one store packets?

One storage structure is to simply have a pool of areas of memory of a stated size. When the controller starts to store a packet it is receiving, it has no idea how large the packet will be, so it grabs a standard buffer and puts a packet into it, whether the packet is large or small. On an ASR9K, we put 2 Gbytes of buffer on a line card, and people tend to assume that means that we can store many seconds worth of traffic. To be honest, I don't know what the buffer structure is on an ASR9K, but I'll bet it is simple linear buffers. If so, it means we can store many small packets and don't have to think too hard about fancy mechanisms for dealing with buffers. When we get larger packets, we're storing the same amount of data, but more compactly. From a fragmentation perspective, it has a significant down side; we have to physically copy data when I fragment packets. That's a big deal.

Another storage structure is to have scatter-gather buffers, with data separate from description. In this case, fragmentation (and reassembly) consist of creating a small buffer for the indicated header attached to a second descriptor that points into the buffer being fragmented. I might therefore receive:

    +--+
    |D1+----+--------------------------------------------+
    +--+    |                                            |
            V start                                      V end
    +-------------------------------------------------------+
    |                       Data                            |
    +-------------------------------------------------------+

and divide it into two messages:

             V start                                      V end
     +-------------------------------------------------------+
     |                       Data                            |
     +-------------------------------------------------------+
             ^               ^^                           ^
             |               ||                           |
             +---------------++----+----------------------+
             |                     |
    +--+   +-++           +--+   +-++
    |D1+-->|D2|           |D3+-->|D4|
    +-++   +--+           +-++   +--+
      |                     |
     ++-+                  ++-+
     |  |                  |  |
     V  V                  V  V
    +----+                +----+
    |HDR1|                |HDR2|
    +----+                +----+

Possible? Yes. I have done it in products I built in the 1980's and 1990's, and it has some similarities to the "particle" data structure used in some of Cisco's products today. Did you say "Terabit"? Hmm. Well, it reduces the data copy overheads, but it also means that the process of chaining two buffers has implications - either I can't simply feed them into a FIFO without ensuring that the FIFO won't underrun (which means that the headers have to have a certain minimum size, as is required by the LANCE), or I have to gather an entire message into some form of memory system before I can start transmitting it. One way or another, it has its own processing loads.

The widespread use of fragmentation/reassembly *can* also mean that some product designs have to be forklift-upgraded, if the buffer design is presumed in hardware and can't be readily changed.

Intellectually, I understand where you're coming from and don't see much of an issue with it. Practically, I think the received wisdom of preferring a solid PMTU design that limits or eliminates the need for fragmentation in the network is a good thing. That falls under "In theory, theory and practice are the same thing". I would *far* rather see hosts implement RFC 4821 (which yields a PMTU result without depending on ICMP) than have fragmentation and reassembly in the network.

My two yen.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 23 May 2012 10:57:51 -0700

Hi Fred,

You raise a number of interesting points. Let me see if I can
follow up below:

> From: Fred Baker [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2012 9:49 AM
> To: Templin, Fred L
> Cc: [email-masked] WG; [email-masked]
> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu
> 
> > Please review and comment on this thread. Remember that this approach is
> proposing something new and different and should be discussed further on
> the list.
> 
> A nit-pick point: I would prefer that the text didn't focus on "1500 byte
> MTUs" as much as simply allowing for larger PMTUs. For example, if I have
> an otherwise 9K-clean path but have a tunnel in it, I wouldn't want the
> tunnel to jack me up from a 1460 byte PMTU to a 1500 byte PMTU by sending
> slightly-too-large packets as packet pairs, one large and one small; I'd

I was actually thinking to have both fragments roughly the same
size; or, certainly no more than 1280/ea. Plus, the fragmenter
has no way of knowing whether the reassembler can do more than
1500 - so, 1500 is the absolute maximum we can achieve.

> want a 9K-clean path, with small packet trains as long as they need to be.

AFAICT, barring congestion the probability of packet delivery
decreases exponentially with the number of fragments. So, if
the delivery probability of a single packet is P, and there
are N fragments, then the delivery probability for the whole
packet is P^N. That is why I want to keep N at 2. 

> You'll notice "1460". I'm also not necessarily thinking about IPv6/IPv4
> tunnels; I'm just as happy to think about IPv4/IPv6 tunnels or IPv6/IPv6
> tunnels.

Yes to the IPv6-in-IPv6 (it's in the draft); not sure
about the IPv4-in-IPv6. The reason I'm not sure is that
IPv4 fragmentation and reassembly is a mess and can't
even be used if the IPv4 packet has DF=1. So, I think
we need some other sort of solution for that.

> I think you can address this comment with a sentence or two up
> front making the point clear, and then globally replacing references to
> tunnel types with the word "tunnel", and references to PMTUs having a
> given value to "PMTU".

I'll see what I can do about this.
>
> As I understand it - quick read - you view an IPv6 end-to-end path as
> being from the addressed source to the addressed destination, and
> fragmentation/reassembly as being a process between the addressed source
> and destination.

Not quite - I am viewing it as fragmentation at the
tunnel ingress and reassembly at the final destination.
This is a key and important point - the tunnel egress
does not need to do anything at all beyond what it
already does.

> Hence, end to end fragmentation and reassembly as
> described in RFC 2460 could go from tunnel endpoint to tunnel endpoint.

As above, it is from tunnel ingress to final destination;
not tunnel ingress to tunnel egress.

> A quick comment on the ident field issue. If you need a 32 bit number to
> take a given value at most once every 60 seconds, one implementation would
> be to have a clock that counts every 14 ns and use its value in the field
> (eg, 4294967296/60=71582788 distinct ident values per second).

Thanks for the good suggestion, and I will have to think
more about it. Having a special clock seems a bit onerous
to me from a layman's perspective however. If you or anyone
else have any other ideas on how to portion the Ident values,
I'm open to suggestions. 

> At the
> point where we have links for which even that isn't fast enough, putting
> multiple EIDs on the same source interface allows you to re-use the clock
> value. I could imagine other uses for the multiple-EID model; if I have an
> input-queued switch and as a result am doing the fragmentation on each of
> a number of ingress line cards that feed to a single egress line card, I
> could associate a different EID with each ingress card (as a source
> address) and give each a separate clock. That way I don't have to
> coordinate the packet streams.

By EID, do you mean the source/destination? If so, then your
point is consistent with Section 4.5 of RFC2460 and is also
allowed by the draft. Having multiple ident counters would
certainly boost the bandwidth - maybe keep a few ident
counters and use some sort of hash function based on
source/destination address to select the counter. That
should allow the tunnel ingress to avoid rate limiting
in may cases.

> My understanding of the reason that the community has moved away from
> fragmentation in the network is the implied unreliability, the processing
> load, and the implications for the intermediate node's internal structure.

I have been assured by at least one equipment manufacturing
person that routers can handle fragmentation at line rates.
Or, maybe I misunderstood him?
 
> which is a talk I gave at LACNIC a couple of weeks ago. Look specifically
> at slide 14. This is a very simple test that I actually did for a
> Networkers talk a decade back. The test setup is:
> 
> Peer 1 and 2 are PCs running some variant on unix, and the routers are
> 26xx series routers connected back to back at 2 MBPS. One could use any
> pair of link speeds one likes as long as one gets a dumbbell topology; the
> value of a relatively low link speed is that you don't have to generate a
> lot of traffic to get the effect. The effect is the some, however,
> regardless of link speed; it's just that numbers scale up and down
> accordingly.
> 
> On Peer 1, I place a file of a large enough size that it's going to take a
> while - maybe ten seconds - to move it to Peer 2 across the intervening
> link. On Peer 2, I open two windows. In one, I start a ping -s to Peer 1,
> and store the output in a file. This will run for the duration of the
> test. In the second window, I run a script. The script will:
> 
>      for N = 1..15
> Offline, I then do some number crunching on the "ping" durations. In sets
> of (IIRC) 11 numbers, I find the least (magenta), the greatest (yellow),
> the arithmetic mean (dark blue), and the standard deviation (light blue),
> and plot them.
> 
> So, in the graphic, going left to right, you see bumps of increasing
> height and width for one FTP session, two, three, four, ..., and on the
> right-most side the bump is for 15 FTPs in parallel. The maximum queue
> depth is Cisco's standard 40 buffers. An interesting implication: at the
> left side, a loss results in a TCP fast retransmit event, while on the
> right side, 40/15 < 3, so we have to assume that every loss (or at least
> many of them) results in a timeout/retransmission. With the pings, we have
> to assume we are getting a sampled measurement - losses only occur when
> there are more than 40 packets in the queue. Hence, I have to believe that
> the drop-off rate noticeable on the fourth through eleventh iterations are
> from slow start driving until there is a loss, and then some FTPs moving
> data a little more quickly than others, so that at the end of the
> iteration they don't all finish simultaneously.
> 
> The key thing I want to point out is this. Especially on the 11..15
> iterations, the queue is at full occupancy most of the time. Hence, the
> points at which we see a tail drop are when Peer 1 sends multiple packets
> in a burst, and it is more likely to be the last packet in the burst that
> is dropped than the first.
> 
> When we fragment packets in the network, we almost by definition get such
> bursts of traffic, meaning that we have an increased probability of
> dropping one of the fragments in a fragmented packet burst. That in turn
> has an embedded attack and creates an embedded point of vulnerability. If
> I am fragmenting packets but transferring them on a multi-path route, I
> can't say "oops, missed that fragment, toss all of the fragments I have
> assembled so far" as I can with PPP Multilink; I have to let them time
> out. So I now have a reassembly failure attack, and if someone wants to
> attack the infrastructure, spoofed source addresses allow him to at least
> consume buffer if not insert data into reassembled datagrams.
> One of the key reasons that people have pushed back hard on fragmentation
> in the network is an observed decrease in reliability of the path.

Well, remember I am only talking about fragment pairs;
not about fragment multiples. Loss unit less than
retransmission unit is certainly a consideration,
but how "bad" is "too bad"?

> The processing load is dependent on the structure of the implementation.
> In any event, doing something is more of a processing load than not doing
> it, so by definition fragmentation and reassembly increase processing
> load. Now, how does one store packets?
> 
> One storage structure is to simply have a pool of areas of memory of a
> stated size. When the controller starts to store a packet it is receiving,
> it has no idea how large the packet will be, so it grabs a standard buffer
> and puts a packet into it, whether the packet is large or small. On an
> ASR9K, we put 2 Gbytes of buffer on a line card, and people tend to assume
> that means that we can store many seconds worth of traffic. To be honest,
> I don't know what the buffer structure is on an ASR9K, but I'll bet it is
> simple linear buffers. If so, it means we can store many small packets and
> don't have to think too hard about fancy mechanisms for dealing with
> buffers. When we get larger packets, we're storing the same amount of
> data, but more compactly. From a fragmentation perspective, it has a
> significant down side; we have to physically copy data when I fragment
> packets. That's a big deal.

Well, as I said the impression I got was that the routers
are much more adept at handling fragmentation now than
they were way back when "Fragmentation Considered Harmful"
hit the streets. And again, it is the host and not some
router that gets to do the reassembly.

> Another storage structure is to have scatter-gather buffers, with data
> separate from description. In this case, fragmentation (and reassembly)
> consist of creating a small buffer for the indicated header attached to a
> second descriptor that points into the buffer being fragmented. I might
> therefore receive:
> 
>     +--+
> Possible? Yes. I have done it in products I built in the 1980's and
> 1990's, and it has some similarities to the "particle" data structure used
> in some of Cisco's products today. Did you say "Terabit"? Hmm. Well, it
> reduces the data copy overheads, but it also means that the process of
> chaining two buffers has implications - either I can't simply feed them
> into a FIFO without ensuring that the FIFO won't underrun (which means
> that the headers have to have a certain minimum size, as is required by
> the LANCE), or I have to gather an entire message into some form of memory

There was an Ethernet chipset called "LANCE" back in the
1980's - is that what you're talking about, or something
else?

> system before I can start transmitting it. One way or another, it has its
> own processing loads.
> 
> 
> The widespread use of fragmentation/reassembly *can* also mean that some
> product designs have to be forklift-upgraded, if the buffer design is
> presumed in hardware and can't be readily changed.

Well, placement of tunnel routers is supposed to be
incrementally deployable - and not required at all
routers.
 
> Intellectually, I understand where you're coming from and don't see much
> of an issue with it. Practically, I think the received wisdom of
> preferring a solid PMTU design that limits or eliminates the need for
> fragmentation in the network is a good thing. That falls under "In theory,
> theory and practice are the same thing". I would *far* rather see hosts
> implement RFC 4821 (which yields a PMTU result without depending on ICMP)
> than have fragmentation and reassembly in the network.

I'm definitely with you on getting all hosts to do RFC4821.
But, it may take a long time between now and then and I'd
rather have working tunnels in the nearer term.

> My two yen.

Worth more than that, IMHO.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 23 May 2012 11:17:43 -0700

> not tunnel ingress to tunnel egress.

Correcting myself, you are correct. It could be a
nested tunnel-within-a-tunnel, in which case the
"final destination" could itself be a router's
tunnel endpoint.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 23 May 2012 11:24:06 -0700

Oh, and another idea; I could make it so that the
tunnel ingress has three "regions" in its MTU
handling:

  1) 1280 or smaller are admitted into the tunnel
     in one piece
  2) 1281 - 1500 are fragmented into two pieces
     before admission into the tunnel
  3) 1501 or larger are admitted into the tunnel
     in one piece

Clause 3) is new, and the idea is this. If someone
wants to do 1501 or larger they had better be using
RFC4821 - then, jumboframes are naturally supported.
That ought to help drive RFC4821 deployment!

Thanks - Fred

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 24 May 2012 09:47:37 +0200

> we need some other sort of solution for that.

The whole DSL (PPPoE session on DSL, with L2TP tunnel backhaul and
wholesale delivery) works on what factually is a tunnel payload MTU of
less than 1500. When used with MSS clamping applied (this is generally
the case - I haven't seen different anywhere yet), this works for
basically almost everyone. About 22 million DSL subscribers in Germany
alone live "happily" with that approach. I don't see why the same
approach doesn't work for DS-Lite too, and field testing for many
months hasn't brought any indication of the contrary.

Can we pretty please fix DS-Lite too while we're at it (fragment the
payload, not the tunnel, and apply MSS clamping to avoid unnecessary
in-transit fragmentation) in the spec / by updating the spec?
Operators are asking vendors for that behaviour anyway to have DS-Lite
operationally deployable. Better have it officially specified.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 May 2012 08:33:36 -0700

Hi Daniel,

Thanks for raising these points, and see below:

> Daniel Roesen
> Sent: Thursday, May 24, 2012 12:48 AM
> To: [email-masked]; [email-masked]
> payload, not the tunnel,

I'd love to be able to fragment the (IPv4) payload,
but AFAICT it can't be done with DF=1. Are you seeing
something I'm not seeing? If not, why not fragment at
the tunnel layer - IPv6 fragmentation and reassembly
supposedly work.

> and apply MSS clamping to avoid unnecessary

AFAICT, MSS clamping is a TCP-only solution. Can we
really generalize and say that it will be good enough
to standardize for all applications everywhere?

Thanks - Fred

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 24 May 2012 18:22:06 +0200

Hi,

On Thu, May 24, 2012 at 08:33:36AM -0700, Templin, Fred L wrote:
> but AFAICT it can't be done with DF=1.

I'm referring only to DF=0. DF=1 needs PMTUD to work, indeed. But that's
what all residential DSL deployments I've "seen" do rely on as well.

> Are you seeing something I'm not seeing?

You mean all the colors that are talking to me? :)

> If not, why not fragment at the tunnel layer

Performance, security.

> AFAICT, MSS clamping is a TCP-only solution.

Indeed.

> Can we really generalize and say that it will be good
> enough to standardize for all applications everywhere?

Well, TCP MSS clamping avoids fragmentation/reassembly on DS-Lite AFTR
and B4. That avoids the performance impact for DF=0 TCP traffic
completely. UDP DF=0 traffic >1460 needs frag/reass still, but that is
reasonably seldom that we can probably just live with it (the DSL world
does - IPv4 in-transit fragmentation is a basic IPv4 router operation
already implemented in CPEs and usually on FPGA/ASIC level on hardware
used as large-scale AFTR). PMTUD copes with DF=1 traffic.

It's not pretty, but it works "good enough" as proven by a three-digit
amount of PPPoE+L2TP residential access lines "out there". We shall not
ignore that experience and trying to follow ivory tower approaches that
are sexy for purists, but we need to find ways to burry IPv4 with the
least cost and risk for all parties involved. Having to do IPv6
reassembly on the AFTR is a significant performance and DoS attack
vector. Avoid.

Best regards,
Daniel

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 May 2012 10:58:16 -0700

Hi,

Since there seemed to be interest in making this even
more generic, I took another cut at the document:

This version now includes considerations for any
IP-in-(foo)-in-IP tunnel type (for "foo" as a null
or non-null midlayer encapsulation). Any comments?

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 May 2012 11:06:15 -0700

Hi,

The draft didn't explain this, but bigger-than-1500
packets are caveat emptor. If I as a source send a
packet bigger than 1500, then I should be prepared
for the possibility that it may be dropped silently.
RFC4821 accounts for such cases.

Thanks - Fred

> Templin, Fred L
> Sent: Thursday, May 24, 2012 10:58 AM

---

From: Mark Andrews <[email-masked]>
Date: Fri, 25 May 2012 09:17:43 +1000

> what all residential DSL deployments I've "seen" do rely on as well.

IPv4 DF=1 => TCP unless you are broken (Linux/Solaris had/have
broken stacks that applied DF=1 to all packets <= interface MTU)
or you are doing something special.

IPv6 DF=1 for *all* traffic as there is no general router based
fragmentation.

Unfortunately this really does mean that people running IPv6 networks
need to learn and *see* the difference between IPv4 and IPv6 and
it doesn't do anyone any long term good hiding that difference.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Washam Fan <[email-masked]>
Date: Fri, 25 May 2012 10:32:11 +0800

Hi Fred,

> That ought to help drive RFC4821 deployment!

When the tunnel ingress is trying to fragment the larger inner packet,
will it also send back ICMP PTB for PMTUD? I don't think it is
clarified in the draft.

Thanks,
washam

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 25 May 2012 08:19:33 -0700

Hi Washam,

> will it also send back ICMP PTB for PMTUD? I don't think it is

You're right. I said that in about 50 of my other
documents on tunnel PMTUD so forgot to mention it
here due to being obvious to me but perhaps not to
others.

The requirement is, that if the packet is larger
than 1500 and is marked "Don't Fragment", the
tunnel must drop the packet and send a PTB if it
is too big to enter the underlying link in one
piece. I'll fix this in the next version.

Thanks - Fred

> From: Washam Fan [mailto:[email-masked]]
> Sent: Thursday, May 24, 2012 7:32 PM
> To: Templin, Fred L
> Cc: Fred Baker; [email-masked]; [email-masked]
> WG