Subject: FW: 6to4 default MTU [was Re: (ngtrans) 6to4 MRU - need WG consensus]

From: "Tony Hain" <[email-masked]>
Date: Tue, 10 Sep 2002 08:09:12 -0700

KRE intended for this to go to the list...
> -----Original Message-----
> From: Robert Elz [mailto:[email-masked]] 
> Sent: Tuesday, September 10, 2002 12:28 AM
> To: Tony Hain
> Subject: Re: 6to4 default MTU [was Re: (ngtrans) 6to4 MRU - 
> need WG consensus] 
> 
> 
>     Date:        Mon, 9 Sep 2002 17:16:11 -0700
>     From:        "Tony Hain" <[email-masked]>
>     Message-ID:  <032001c2585f$44e91aa0$011aa8c0@eagleswings>
> 
>   | If any specific receiver
>   | can't support an IPv4 MRU larger than 1280, the IPv6 PMTU 
> discovery will
>   | fail until it gets down to an acceptable value. The only real
>   | interoperability problem will be when the IPv4 MRU is 
> less than 1280.
>   | Everything else is simply an optimization.
> 
> Actually, no it isn't, and this is the point.   Packets 
> exceeding the MRU
> generally just get dropped (unless something implements the 
> idea that Christian suggested, which currently, I know of 
> nothing that does). No ICMP gets sent back.
> 
> That is, PMTUD doesn't find this problem, what happens is a 
> black hole.
> 
> This is the problem that Itojun pointed out in the first place.   His
> suggested fix was to nail down the MTU, but we don't need to 
> do that - all we need is to guarantee an MRU that everyone 
> has to accept - and then, as you say, the MTU can be set 
> anywhere between 1280 and that MRU and PMTUD will do the rest.
> 
> The problem with your earlier suggestion, and Brian's ...
> 
>   | Although I'd dearly like to see larger packet sizes in 
> use, we've been
>   | waiting many years to get above 1500 and I think we'll 
> wait a lot longer.
>   | And we're only specifying a *minimum* MRU. 
> 
> is that we need a MRU that is known, because (without 
> specific knowledge of the destination, which 6to4 is all 
> about avoiding the need for), the biggest MTU value that can 
> be set is that known MRU.
> 
> Since I have no idea what interfaces a remote node might 
> have, if the requirement was just "the biggest MTU of any of 
> your interfaces", then I know nothing at all about its MRU, 
> and really can do no better, ever, than send 1280.
> 
> Its the same with the "*minimum* MRU" - sure, nodes can have 
> bigger ones, but without config, which 6to4 doesn't have, no 
> sender can ever assume this. That is, whatever we specify as 
> the minimum required MRU now, will effectively be the maximum 
> permitted MTU for any 6to4 sender, for ever.
> 
> Lastly, while I'm here (to keep my message count on this down) ...
> 
> [email-masked] said:
>   | all this discussion of mtu seems to forget the problems 
> with delivering
>   | v6 or signed dns data. 
> 
> Yes.   It does.   That's because this is completely irrelevant.   IPv6
> specifies a minimum required MTU of 1280.   That's all anyone 
> who isn't
> doing PMTUD (which DNS servers will rarely ever do) can ever assume.
> 
> So, a DNS server, however big the packet is that it wants to 
> send, needs to
> keep its IP packets to 1280 or smaller.   It can do that by 
> simply limiting
> the reply to 1280 (setting TC if required) or it can do it by 
> transmitting IPv6 fragments (basically pretending that it had 
> done PMTUD, and that 1280 was the answer it received, 
> regardless of what the path might be able to
> support).   Which of those is appropriate will depend upon 
> the capabilities
> of the server, the preferences of its maintainer, and what 
> available buffer size the resolver specified in the EDNS0 OPT 
> RR that accompanied the query (assuming there was one - if 
> not, 512 is the answer, or perhaps 1280 if the query 
> transport is IPv6, and we actually remembered to write down 
> that change somewhere - I don't remember if that happened).
> 
> What the actual PMTU is, is 100% irrelevant to a DNS server 
> usually, and so whether or not there's a 6to4 tunnel in the 
> path, and whether or not that happens to actually be the 
> choke point on the PMTU is absolutely irrelevant.
> 
> The issue above would only be relevant were we discussing 
> what the minimum MTU permitted on any IPv6 link should be - 
> but we're not.
> 
> kre
>

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 12 Sep 2002 14:02:30 -0700

> A different question would be, if we don't see a significant shift to
> native IPv6, how likely is it that 6to4 would even work in a highly
> nat'd world of 10-15 years from now? If we were having this discussion
> about teredo I might buy it's applicability.

The Teredo spec actually specifies using the minimal MTU. UDP
fragmentation is even worse than IP fragmentation: NAT/firewalls don't
pass the packets through if the port numbers don't match some
preexisting context; some of them do not perform packet reassembly, and
thus drop any but the first segments.

-- Christian Huitema

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 17 Sep 2002 14:37:40 -0700

Whoops! In re-reading your message, I now see that you said:

  "I haven seen an easy way to combine all four."

I parsed this as: "I *have* seen an easy way...", but perhaps
you really meant: "I *havn't* seen an easy way...". Which one
is it?

Fred
[email-masked]

Fred L. Templin wrote:
 > Erik Nordmark wrote:
 >  >>Interesting document - thanks for pointing it out. Have you had a chance
 >  >>to read it? If so, what is your assessment of the "How to detect" and
 >  >>"How to fix" suggestions given in section 2.1 from the standpoint of
 >  >>robustness and efficiency?
 >  >
 >  >
 >  > I think it is a bit tricky because there are multiple things you'd might
 >  > want to trigger when the transport protocol is retransmitting.
 >  > For instance in IPv4 you want to trigger dead gateway detection.
 >  > And in an SCTP case you might want to try an alternate path for
 >  > the retransmitted packets.
 >  > Thus transport retransmissions might be due to at least
 >  >  - loss due to congestion
 >  >  - loss due to lossy (e.g. wireless) links
 >  >  - loss due to the path having failures (1st hop router or some other
 > part
 >  >    of the path)
 >  >  - loss due to sending large packets and the ICMP too big not being
 > returned
 >  >
 >  > The TCP specification handles the first two.
 >  > The SCTP specification handles the first three even though the
 > heuristics
 >  > for path failures are really basic.
 >  >
 >  > I haven seen an easy way to combine all four.
 >
 > Does your easy way handle both TCP and SCTP? What about persistent UDP
 > sessions? How about multicast? Finally, do you plan to enlighten us all
 > during the v6ops meeting tomorrow?
 >
 > Fred
 > [email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 20 Sep 2002 09:51:05 -0700

Erik Nordmark wrote:
 > Missing "'t" above.
 > "have not".

I guess your finger must have slipped on the "t" key; either that,
or the mailer somehow clipped it out of your message.

 >>Finally, do you plan to enlighten us all during the v6ops meeting tomorrow?

My mistake on this; I somehow assumed you would be attending. I really need
to check those attendees lists more carefully...

Fred
[email-masked]