<html><head>
<meta content="text/html; charset=ISO-2022-JP" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br style="font-family: 
Courier New,Courier,monospace;">
<br style="font-family: Courier New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">Yasuhiro 
Orange Morishita / $B?92<BY9((B wrote:</span>
<blockquote style="font-family: Courier New,Courier,monospace;" 
cite="mid:20130911.022021.46342557.yasuhiro@jprs.co.jp" type="cite">
  <blockquote type="cite"><pre wrap="">And I know the IP specification defines the minimal MTU size to 576.
So, we may need a very short RFC for updating the definition of MTU,
</pre></blockquote>
  <pre wrap=""><!---->                                                                     ^
                                                                    to 1280

-- Orange

</pre>
  <blockquote type="cite"><pre wrap="">in RFC 791.</pre></blockquote>
</blockquote>
<br style="font-family: Courier New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">i do not think
 that the definition of mtu is wrong. if i were going to update 6891-bis
 (which is itself 2671-bis) the logic i would draft is:</span><br 
style="font-family: Courier New,Courier,monospace;">
<br>
---<br>
<br style="font-family: Courier New,Courier,monospace;">
<span style="font-family: Courier New,Courier,monospace;">"A DNS UDP 
responder shall, when transmitting a message which does not include 
embedded cryptographic signatures such as TSIG or DNSSEC signatures, use
 an effective DNS message payload size which is calculated as 
MIN(OFFERED, MIN(DISCOVERED, ESTIMATED) - OVERHEAD)) where OFFERED is 
the EDNS BUFSIZE received from the initiator, and DISCOVERED is the path
 MTU if known or else the outbound interface MTU, and ESTIMATED is 
chosen as 576 for IPv4 or 1280 for IPv6 as the minimum guaranteed size 
of an IP datagram, and OVERHEAD is chosen as 64 for IPv4 or 48 for IPv6 
as the maximum likely size of the IP and UDP headers.<br>
  <br>
This specification does not define a maximum for any future IP transport
 protocol, and so both initiators and responders should be prepared to 
receive messages as large as the 9 kilobyte ethernet jumbogram size in 
preparation for future transport protocol development."<br>
  <br>
---<br>
  <br>
i'm trying to decide whether that "should" ought to be a "must". and, i 
know the number is 9K not 64K, because of buffer memory considerations 
on today's embedded servers.<br>
  <br>
vixie<br>
  <br>

</span>
<blockquote style="font-family: Courier New,Courier,monospace;" 
cite="mid:20130911.022021.46342557.yasuhiro@jprs.co.jp" type="cite">

</blockquote>
</body></html>