[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [RRG] MTU/fragmentation AGAIN



Brian,

I probably didn't look at your proposal carefully enough,
and I may not have time to soon. But, regardless of
whether/not PTBs could be translated there is still a
trust issue. We can probably (hopefully!) trust PTBs from
a router within the same site (i.e., intra-domain). But,
the same may not be true for PTBs that come from outside
of the site (inter-domain) and these may in fact be used
as a DOS vector. To my understanding, inter-domain is the
deployment case for the map-and-encaps architectures we
have been discussing?

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: Brian Dickson [mailto:briand@ca.afilias.info] 
> Sent: Thursday, January 03, 2008 4:54 PM
> To: Templin, Fred L
> Cc: Iljitsch van Beijnum; Routing Research Group list; Dino 
> Farinacci; Tony Li
> Subject: Re: [RRG] MTU/fragmentation AGAIN
> 
> Templin, Fred L wrote:
> > Brian,
> >   
> >> The real benefit is that, like SIIT, it is feasible to do ICMP 
> >> transliteration, thus support PMTUD and similar activities.
> >> That, and not affecting the PMTU itself in the first place. :-)
> >>     
> >
> > Among the myriad issues that have us scratching our heads,
> > SIIT doesn't work when a middlebox returns an ICMP PTB that
> > only includes the minimum 8 bytes beyond the IP header of
> > the packet-in-error.
> >   
> Hmm. I can see how that PTB issue would break SIIT.
> 
> However, when doing 1:1 NAT (no port changes, only swapping prefix 
> portions of src and/or dst),
> it does not appear (to me at least) to cause any problems.
> 
> The PTB message would get sent to the NAT'd sender address, which the 
> ITR would need to properly
> un-NAT (including the payload IP header src/dest).
> 
> That un-NAT function, however, would be completely 
> deterministic, under 
> the proposed scheme.
> RLOC->EID would be guaranteed to be a 1:1. (Several RLOCs can 
> map to the 
> same EID, of course...)
> 
> At least, I think this is the case. If the real sender, 
> sending with its 
> own EID as src, receives a PTB, and the IP header
> inside the PTB matched the header of a sent packet, that should be 
> enough for PMTUD to work, should it not?
> 
> And since the packet sizes wouldn't change, the MTU of the PTB would 
> still be valid.
> 
> Am I missing something?
> 
> (This is IPv6-to-IPv6 mapping, effectively 1:1 NAT on 
> src/dest, rather 
> than tunneling packets. No S*IT is involved.)
> 
> Brian
> 

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg