Hi,

----- Original Message -----
> From: C. M. Heard <[email protected]>
> To: IPv6 <[email protected]>
> Cc: 
> Sent: Friday, 2 August 2013 3:11 AM
> Subject: Re: UDP+Fragmentation (was: "Deprecate")
> 
> On Thu, 1 Aug 2013, RJ Atkinson wrote:
>>  I agree that C.M. Heard's ideas should be explored
>>  in more detail by the IETF.  
> 
> Not just my suggestion, but other ideas as well:
> 
> - put UDP source and destination ports in a new IPv6 option that and 
>   add it along with a fragment header when fragmenting UDP packets 
>   (suggested on-list by Mark Andrews).
> 
> - generic transport encapsulation within UDP (suggested to me
>   off-list by Mark Smith, based on a draft by Stuart Cheshire 
>   et. al.).
> 

For those on the list, the draft I mentioned was :

Encapsulation of TCP and other Transport Protocols over UDP
http://tools.ietf.org/html/draft-cheshire-tcp-over-udp-00


Note that this basically proposes translating the TCP header into UDP header 
fields, and then for the missing fields, appending them after the UDP header. I 
was a bit confused by what was proposed, until I thought about a web server 
specifically listening on UDP port 80, knowing that UDP port 80 is TCP over 
UDP, and then decoding the UDP fields and subsequent fields as a TCP header.


> - SEAL (suggested on-list by Fred Templin)
> 
>>  (I defer to the Powers That Be which list that might
>>  belong to -- TSV WG list might be one option, but
>>  it is not as likely to have IPv6 operators as well
>>  represented as the IPv6 list seems to have.)
> 
> That's really important -- it doesn't do anyone any good to have a 
> theoretical solution that operators are not willing to deploy.  We 
> all need to work together here.
> 

Actually, it has occurred to me that there are two fragmentation related 
problems, rather than one:

(1) fragmentation doesn't work reliably

(2) fragments can hide transport layer protocol ports, preventing simple ACL 
filtering etc.

The reaction to (2) of dropping fragments causes (1).

A general solution like SEAL (which I think in the big picture would be 
better), probably doesn't solve (2) (I assume, I've had nothing more than a 
brief look), so the people who care about (2) won't find SEAL or similar 
addresses their problem.

Regards,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to