Re: [BEHAVE] Amount of fragmentation resulting from translation
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BEHAVE] Amount of fragmentation resulting from translation
In message <4AEA18CE.8040302 at venaas.com>, Stig Venaas writes:
> Iljitsch van Beijnum wrote:
> > On 29 okt 2009, at 09:14, marcelo bagnulo braun wrote:
> >
> >> So, my question is whether this behaviour would not result is massive
> >> fragmentation. I mean, one could guess that 1500 byte long packet are
> >> fairly common, and that the defined behavour would imply fragmentation
> >> of all these packets for example.
> >
> > Right. Of course most traffic is TCP which has PMTUD enabled so DF=1,
> > but there is some TCP with DF=0 and UDP video streaming usually has ~
> > 1470 byte packets and DF=0.
>
> A hybrid approach might be useful. E.g. if the IPv4 packet is translated
> into an IPv6 packet > 1280, try to send it. If you get ICMP back, just
> do 1280. Anyway, I think this should be left to the implementation.
> Doing PMTUD would be good in my opinion, but alternatively, just assume
> 1280. Just like IPv6 hosts have to do.
>
> > The problem is that if you translate IPv4 packets with DF=0 and they're
> > too big on the IPv6 side, an IPv6 router will send back a too big
> > message, and if you translate that message to an IPv4 too big message it
> > will probably be ignored because UDP protocols have to do their own
> > PMTUD in IPv4 which they don't AFAIK, and in the case of TCP with DF=0
> > PMTUD was almost certainly turned off.
>
> Yes. I think if DF=0 you just have to fragment. You cannot assume PMTUD
> will work. You still have the choice whether to do PMTUD or assume 1280
> on IPv6 side of course.
>
> > So in the case where the IPv6 MTU is smaller than the IPv4 MTU (and 20
> > bytes for the difference between the v6/v4 header sizes) for packets
> > with DF=0 you need to fragment. That means the only question is whether
> > you simply always fragment, or track the PMTU on the IPv6 side and only
> > fragment when necessary.
> >
> > Since any IPv6 host needs to track the PMTU for any host it talks to
> > anyway (if it wants to send > 1280 byte packets, at least) the state
> > requirement doesn't seem very unusual so I would go for that. But maybe
> > others would prefer the other choice.
>
> Yes, I think it's OK doing PMTUD. But I still think it can be optional.
> I prefer the additional state (if translator can cope with it) to having
> all the extra fragmentation. Of course there will probably be some
> issues due to some IPv4 senders sending 1500 byte packets, where the
> IPv6 receiver is also likely to handle at most 1500.
>
> Stig
I think turning on PMTUD in the middle of the network is just plain
wrong. There are OS which incorrectly turn on PMTUD for IPv4 for
all packets. This causes problems for applications like DNS servers.
There is only one choice and that is to fragment at network MTU. Anything
else will cause operational problems.
> > On 29 okt 2009, at 09:40, Reinaldo Penno wrote:
> >
> >> As far as PMTUD goes although it creates state, you need to remember such
> >> values per outgoing interface and not really per NAT binding.
> >
> > No, it's per IPv6 destination address. Could be that one host that uses
> > the translator can handle 1500 byte packets while another can only
> > handle 1480 or 1280.
> > _______________________________________________
> > Behave mailing list
> > Behave at ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
>
> _______________________________________________
> Behave mailing list
> Behave at ietf.org
> https://www.ietf.org/mailman/listinfo/behave
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.