Re: UDP+Fragmentation (was: "Deprecate")

Ron,

On Aug 1, 2013, at 10:37 AM, Ronald Bonica <rbonica@juniper.net> wrote:

> Cmh,
> 
> When I read this message, my first reaction was to scream "that such a thing could not possibly be deployed, because operators will filter anything that they don't know or have an immediate use for." But after a few hallway discussions, I am starting to think that the idea might be viable.
> 
> When the adrenaline and endorphin rush of IETF week has subsided, we should a) discuss whether this is a viable option and b) if so, define the replacement protocol in the Transport Area.
> 
> Chairs,
> 
> The conversation proposed above may not be within the charter of 6man. If/when you think that there is a need to move this conversation, I can ask the transport Ads for a non-WG mailing list. However, if you are happy for at least the first part of this conversation to occur on this mailing list, we can continue here.
> 
> 

My personal opinion is that the conversation can start on 6man.  We have some history of how to make TCP and UDP work over IPv6, so I think it's OK to start here.  I am sure the ADs will decide to move it gains steam and they wish it elsewhere.

Thanks,
Bob

> 
> 
>> -----Original Message-----
>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
>> C. M. Heard
>> Sent: Wednesday, July 31, 2013 12:40 AM
>> To: IPv6
>> Subject: RE: "Deprecate"
>> 
>> On Tue, 30 Jul 2013, Ronald Bonica wrote:
>>> Thinking a little more about it, RTP and UDP aren't the real
>> culprits.
>>> The culprits are the applications that run over them.
>>> So, we should limit our statement to applications, and not
>>> "applications and transport layer protocols".
>> 
>> I don't agree, at least not if the principal reason why IP fragments
>> get dropped is that they lack the L4 header (or at least that the non-
>> initial fragments do) and thereby break stateless ACLs.  The problem is
>> that UDP and its kin such as UDP-lite and DCCP lack transport-layer
>> segmentation, such as is present in TCP, and are thereby force their
>> clients to rely on IP fragmentation to provide this service.  So yes,
>> these transport protocols are the culprits.
>> 
>> The idea that immediately comes to mind is to design _replacements_
>> transport protocols for UDP and kin that contain a transport layer
>> segmentation mechanism.  These would be for use by applications that
>> can't get by without such a mechanism; existing applications that don't
>> need to rely on IP fragmentation can continue to use UDP and kin.  The
>> replacement for UDP might have a header that looks something like this:
>> 
>>   0                            15 16                            31
>>  +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
>>  |         Source Port           |      Destination Port         |
>>  +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
>>  |            Length             |       Segment Offset    |Res|M|
>>  +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
>>  |                         Identification                        |
>>  +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
>>  |                            Checksum                           |
>>  +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+
>>  |                          data octets               ...
>>  +-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|    ...
>> 
>> (Other and perhaps better possibilities exist, of course.)
>> 
>> Having said that, I immediately imagine screaming that such a thing
>> could not possibly be deployed, because operators will filter anything
>> that they don't know or have an immediate use for, and so it would
>> never get any traction.
>> 
>> Well, maybe so, but something has to give.  The operations folks have
>> complained that IP fragmentation is awful, they have to filter
>> fragments because it defeats their stateless ACLs.  OK; let's agree
>> that's a defect that needs to be fixed.  But if you don't want the fix
>> to break other important stuff (e.g., DNSSEC, as metioned in Section
>> 3.1 of draft-bonica-6man-frag-deprecate-02), you need a replacement for
>> IP fragmentation (or an augmentation, such as in
>> http://www.ietf.org/mail-archive/web/ipv6/current/msg18389.html by Mark
>> Andrews).  Maybe I just lack imagination, but I can't see any fix that
>> does not involve SOME change in operator behavior.
>> 
>> //cmh
>> --------------------------------------------------------------------
>> 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
> --------------------------------------------------------------------