In message <ee995320-48d6-4d97-888a-0c2ad5024...@apnic.net>, Geoff Huston write s: > Hi, > > We _are_ seeing IPv6 packet fragmentation in TCP over IPv6, and the = > causes are systematic, rather than random chance. > > What is happening is that the client is behind some form of tunnel = > (MPLS) we _assume_. The server (FreeBSD recent version) is sitting with = > a MTU of 1500, as is the client. > > The client opens 5 ports in parallel (possibly firefox???) The client = > makes a request down port 1, then, a little later, makes another request = > down port 2. The server sends large packets down the TCP session open to = > port 1. A gateway on the path sends back an ICMP6 packet too big to the = > server for this TCP session, with a new MTU of 1492. The TCP session on = > port 1 now adjust its MSS to 1432 (=3D1492 - 60) and the server resends = > its set of data as a sequence of packets each of which is 1492 octets in = > size - all good, no fragmentation of TCP packets so far. > > But then, on the session open to the client's port 2 the server = > assembles its set of packets for the second request to send to the = > client. The TCP session on the server which is bound to port 2 of the = > client is unaware of the MTU change (after all, the ICMP6 PTB message = > was directed to the TCP session that is bound to client port 1, not port = > 2), and the server's IPv6 driver gets a set of 1440 octet TCP payload = > packets to send to the client. But there is a data structure in the = > server (I think FreeBSD uses the routing table, but the FreeBSD folk = > probably know better than I do which internal table is used to cache = > path MTU data derived from ICMPv6 PTB messages) which says that for this = > IPv6 destination address the new MTU is not 1500, but is 1492. The IPv6 = > output driver now fragments the queued TCP packets to session connected = > to the client port 2 to send 2 packets for each single packet passed to = > it from the upper level TCP driver, and what heads onto the wire is a = > 1420 octet payload and a 20 octet payload, with IPv6 fragmentation set = > to bind them together. > > As far as I can see this is not "bad" behaviour. The second session has = > not received it own ICMP6 packet too big, so this TCP session (and all = > other parallel TCP sessions) are unaware of the need to drop its MSS, = > and because of the cached per host entry with the new MTU the IP driver = > is aware that it cannot send these packets out without fragmentation. So = > the IP layer is aware of this lower path MTU and correctly fragments the = > TCP packet to ensure delivery. I don't believe this is a bug per se. I = > think its an unintended side effect of the way in which ICMP6 PTB = > messages are processed by the recipient. > > How prevalent is this behaviour? > > Well, how prevalent are browsers that open up parallel ports to the same = > destination? > > Gee, with today's browsers just about everyone does this! > > If you want to deprecate IPv6 fragmentation and still allow this form of = > parallel session behaviour to work rather than wedge, then the internal = > handling of ICMPv6 PTB messages in the host needs to be reworked as far = > as I can tell. > > thanks, > > Geoff
Which probably is some of the cause of some of the fragements I am seeing. I went looking for just such behaviour on pages I normally visit and saw the above behaviour. Note this on only on the initial page load. On reload no fragmentation is seen which is to be expected. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
