Re: [v6ops] Prep for v6ops IETF 84 agenda

On Jun 29, 2012, at 12:34 AM, Templin, Fred L wrote:

>> -----Original Message-----
>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
>> Fred Baker (fred)
>> Sent: Sunday, June 24, 2012 7:05 PM
>> To: v6ops@ietf.org WG
>> Cc: Ron Bonica
>> Subject: [v6ops] Prep for v6ops IETF 84 agenda
>> 
>> I sat down this morning to assess our agenda. Interested in working group
>> comment.
> 
> OK Fred; I'll bite. Why are you listing 'draft-generic-v6ops-tunmtu'
> as "#out of charter"?

Because changes to section 4.5 of RFC 2460 ("a source node may divide the packet...") is a change to RFC 2460, and should be discussed by the folks maintaining RFC 2460. 

Begin forwarded message:

> From: "Fred Baker (fred)" <fred@cisco.com>
> Date: June 23, 2012 5:43:22 AM GMT+08:00
> To: Fred Templin <Fred.L.Templin@boeing.com>, "v6ops@ietf.org WG" <v6ops@ietf.org>
> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu
> 
> Coming back to this as a meta-issue.
> 
> v6ops is about operational considerations and procedures, but not protocols; disputing RFC 2460, aka redesigning IPv6, seems like a protocol issue.
> 
> The reason to not do inner fragmentation, if memory serves, has to do with the behavior of fragmentation in the network and its effect on communications. For example, suppose you and I are in 9K clean networks (so the TCP MSS starts out as 9K), my link to the public network has an MTU of 1500, and somewhere en route to you there is another link with an MTU of 1400. When I send a 9K packet, it will become six 1500 byte packets with a small caboose that picks up the size of five IP headers (IPv4 or IPv6), and what you will receive is six 1400 byte packets interspersed with six 100+IP byte packets, followed by the original caboose. What if the fragmenting router's queue, at the time of fragmentation, was one packet short of the needed capacity? Maybe the retransmission follows a different path and is fragmented differently, resulting in funny overlaps whose handling isn't very well specified. There's nothing *incorrect* about a stream of 13 packets of various sizes being reassem
> bled, but integrating retransmissions gets messy. IIRC, they just wanted to clean that up.
> 
> Which brings me to the following consideration.
> 
> If we're talking about having one tunnel endpoint put a message into a tunnel datagram and then fragment it, and have the other tunnel endpoint reassemble the original and forward it, we are talking about an operational procedure that requires support in a router, but which I can correlate with section 5 of RFC 2460.
> 
> One thing I would invite is discussion of operational experience with RFC 4821. Wouldn't it be nice if the endpoint actually chose an MSS based on what actually worked (shades of Happy Eyeballs), rather than depending on error messages that network operators routinely filter out?
> 
> If we're talking about changing the recommendation of RFC 2460 regarding who does fragmentation, that sounds like an IPv6 protocol change, and I'd like to refer that to 6MAN.
> 
> Does that make sense?
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops