[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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