[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