[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt

On 10/28/09 6:44 AM, Alfred ï wrote:

Alfred,


At Tue, 27 Oct 2009 16:57:40 -0700, Doug Otis  wrote:

...
Updating RFC 1123 should consider the functional alternative made
possible with RFC2671.  The maximal DNS message size of 512 should
not reflect a 576 MTU, but that of 1476 MTU. Only beyond that limit,
should TCP become required.  After all, most CPE equipment can not
proxy DNS over TCP, so DNS operation is not better accomplished with
this over reaching TCP mandate.
...


Although perhaps 1476 might be desirable, it seems ill-advised to
ask for that.  We should align the limit to what already has found
consensus in the IETF for IPv6 in particular, and what link layer
specifications since then have learned to accommodate.

RFC 2460 specifies (on page 24):

|5. Packet Size Issues
|
|   IPv6 requires that every link in the internet have an MTU of 1280
|   octets or greater.  On any link that cannot convey a 1280-octet
|   packet in one piece, link-specific fragmentation and reassembly
|   must be provided at a layer below IPv6.

This limit has been chosen then with various tunnelling technologies
in mind, leaving enough head room for additional tunnel headers etc.
before reaching the traditional Ethernet packet size.
Yes it would cause fewer issues for tunneling IPv6 to impose an alternative to UDP jumbo frames when MTUs are larger than 1280 bytes. 


Also, there now indeed are wireless technologies that needed such
convergence layer to adapt the much smaller L2 packet size to the
IPv6 requirement.
We cannot expect anybody will change the boundary again, solely
because this WG would appreciate it (other folks as well, surely!).

>


The overwhelming majority of link layers for IPv4 should actually
accommodate the same limit today.  (Can somebody please quantify
this assumption based on empirical data? -- Maybe router vendors
will know best, and field tests might help to confirm the results.)

Since avoiding IP layer fragmentation is one of the most important
goals, from an operational and security perspective, we therefore
should contend with the future-(IPv6-)proof packet size limit.
Agreed. However, how much IPv6 tunneling of UDP would be affected by a 1476 MTU cut-off for DNS over UDP? Less than 1%? And how much more DNS traffic could then be handled by UDP with the 196 additional bytes? Surely this would cause less harm than 4096 byte MTUs. There is no desire to argue about this difference, but a TCP mandate at the 576 byte MTUs is clearly wrong.
Imposing _any_ TCP mandate represents an expedient that takes DNS in the wrong direction. As such, this draft should also include a strong warning that resources needed to sustain TCP services might be provisioned for other transports during aberrant demand, and that it is not recommended to be dependent upon TCP availability. 


I further suggest that DNSEXT should push the emerging INTAREA WG
to consider aligning the MTU requirements for IPv4 with those for
IPv6 (as quoted above).  This in turn would then allow this WG to
consider raising the mimimum UDP packet size for DNS as well.
Please comment on the INTAREA WG Review call archived at:
http://www.IETF.ORG/mail-archive/web/ietf-announce/current/msg06684.html
Imposing a TCP mandate when DNS messages exceed 512 bytes allows compliance with seldom used 576 byte MTUs. A TCP mandate at this MTU size makes little sense when it will likely increase TCP traffic DNS servers are thereby _mandated_ to provide. Expecting use of UDP up to either 1476 or 1280 byte MTUs still substantially limits reflected attack and packet fragmentation. 


This IMHO is the proper temporal sequence of tasks.  I fear DNSEXT
would most likely fail in IETF LC and in the IESG if it attempted
to implicitely change the IPv4 specs in this way.

On the other hand, this means that the "MUST implement" requirement
for TCP Transport of 'normal' (non-{A|I}XFR) DNS traffic is still
needed, with as few exceptions as possible for DNS components,
and with _no_ exceptions for middleboxes.

Furthermore, it might be wise to request *middlebox* support for DNS
packets of (at least?) 4096 octets *today*, over any DNS transport.
It seems not reasonable to expect useful seamless deployment of any
increase in the DNS packet size (via EDNS, TCP transport, 'upgraded'
or IPv6-based UDP transport, or any future DNS transport) unless we
*first* happen to achieve adherence at large to this requirement!
It would seem this request has been made long ago, but adherence creates other problems less easily solved without complete adherence. 

-Doug