> -----Original Message-----
> From: Lee, Yiu [mailto:[email protected]] 
> Sent: Wednesday, October 27, 2010 1:55 PM
> To: Templin, Fred L; Rémi Després
> Cc: Softwires
> Subject: Re: 
> [Softwires]I-DAction:draft-lee-softwire-dslite-deployment-00.txt
> 
> Hi Fred,
> 
> I am not saying to disable fragmentation. All we say is to ask b4 to
> fragment the packet and AFTR to reassemble it. We are on the 
> same page.

I am just dropping in and have not followed the discussion
closely, but if you are asking for reassembly by a network
middlebox element then I disagree. End system OSs are not
dumb and have had working IP reassembly implementations
for decades. AFAICT, they do not have to be coddled by
intelligent middleboxes that think they know better.

Destination end systems will benefit from receiving the
fragments since they will then have knowledge of when to
tell the source end systems that they are fragmenting. Also,
fragmentation and reassembly may be by a mutual agreement
between source and destination end systems which would be
disrupted by reassembling middleboxes. Plus, due to routing
changes a reassembling middlebox may have no way of knowing
whether it will see all of the fragments of the same datagram.
And for sure, a reassembling middlebox will have no way of
knowing whether further fragmentation will occur on the
path to the destination.

I have heard something about "virtual fragment reassembly"
(sic) and if I understand the idea correctly I'm not sure
I like it. Is this what you had in mind?

Fred
[email protected]

> Yiu
> 
> On 10/27/10 4:43 PM, "Templin, Fred L" 
> <[email protected]> wrote:
> 
> > 
> >
> >> -----Original Message-----
> >> From: [email protected]
> >> [mailto:[email protected]] On Behalf Of Lee, Yiu
> >> Sent: Wednesday, October 27, 2010 9:38 AM
> >> To: Rémi Després
> >> Cc: Softwires
> >> Subject: Re: [Softwires]
> >> I-DAction:draft-lee-softwire-dslite-deployment-00.txt
> >> 
> >> There are many recorded attacks about IP fragmentation
> >> (search for Rose
> >> Frag attack). Some firewalls are smart enough to identify
> >> whether it is a
> >> real attack or not. Some simply drop any fragmentation
> >> packet. I am not
> >> going to argue which is a better policy. My point is if we
> >> can limit the
> >> fragmentation only happening between b4 and AFTR, this will
> >> save us a lot
> >> of headache in future.
> >
> >Hold on there. Fragmentation and reassembly is a fundamenal
> >function of the IP service model - has been for decades.
> >There are major Internet services that serve content while
> >setting DF=0. Isolated large packets that must be delivered
> >without being lost due to an MTU restriction use DF=0.
> >End-to-end fragemntation and reassembly between consenting
> >end systems is also available even if the network itself
> >does not fragment. Are you saying we should disable a
> >fundamental function of the IP service model? And trace
> >down all of the places where things would break as result?
> >
> >Fred
> >[email protected]
> >
> >> On 10/27/10 12:07 PM, "Rémi Després" <[email protected]> wrote:
> >> 
> >> >
> >> >Le 27 oct. 2010 à 17:50, Lee, Yiu a écrit :
> >> >
> >> >> Not the servers, but the firewall in front of the servers.....
> >> >
> >> >Well, that's different.
> >> >But is it normal for a FW to refused fragmented IPv4 datagrams?
> >> >It seems to me that would seriously limit connectivity.
> >> >
> >> >RD 
> >> >
> >> >> 
> >> >>>> If B4 fragmented the v4
> >> >>>> packet, this is a possibility that the target server 
> may drop the
> >> >>>> fragmented v4 packet due to security concerns.
> >> >>> 
> >> >>> I miss the point.
> >> >>> I don't see why servers would refuse fragmented datagrams
> >> for security
> >> >>> reasons.
> >> >
> >> >
> >> 
> >> _______________________________________________
> >> Softwires mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/softwires
> >> 
> 
> 
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to