Skip to main content

IP Fragmentation Avoidance in DNS
draft-ietf-dnsop-avoid-fragmentation-16

Revision differences

Document history

Date Rev. By Action
2024-01-26
16 Gunter Van de Velde Request closed, assignment withdrawn: Nagendra Nainar Last Call OPSDIR review
2024-01-26
16 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Team Will not Review Version': Cleaning up stale OPSDIR queue
2024-01-04
16 (System) Changed action holders to Kazunori Fujiwara, Paul Vixie (IESG state changed)
2024-01-04
16 Jenny Bui IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2024-01-04
16 Éric Vyncke
[Ballot comment]
Thank you for this document, DNS is so important for the global Internet that a BCP is welcome. I am afraid that for …
[Ballot comment]
Thank you for this document, DNS is so important for the global Internet that a BCP is welcome. I am afraid that for several reasons I was unable to review correctly this document on time, mainly relying on Vladimír Čunát's DNS-dir review at https://datatracker.ietf.org/doc/review-ietf-dnsop-avoid-fragmentation-16-dnsdir-telechat-cunat-2023-12-27/ .

Nevertheless, I support Rob's DISCUSS about the use of MAY/SHOULD about the IPv4 DF-bit in section 3.1; also, an assertion like `many OS kernel constraints make it difficult to set the DF bit` should be backed by a reference.

I also find 'light' to rely on TCP MSS as it is set by the end points only, i.e., it can also leads to IPv4 fragmentation in the path (or IPv6 fragmentation by the kernel at the source).

Section 3, does `These recommendations are intended for nodes with global IP addresses on the Internet` also cover the use of NAT/NPT when the requestor uses RFC 1918 addresses or ULA?

In section 3.1:

- R1 why not simply stating that there should be no IPv6 fragmentation ? Atomic fragments are now discouraged for IPv6

- R3 where is the packet size of 1400 coming from ? Some reasoning would be welcome (e.g., based on some measurements over the global Internet). Put at least a forward reference to the appendix.

In section 4, R9: where is `13 may be too large` coming from ?

Appendix `the authors' recommendation` is it a recommendation by the authors or by the IETF in an IETF stream document?

-éric
2024-01-04
16 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2024-01-04
16 Lars Eggert
[Ballot comment]
# GEN AD review of draft-ietf-dnsop-avoid-fragmentation-16

CC @larseggert

Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/VBI2ri6JwD9TEPjcxKBi828dVs4). …
[Ballot comment]
# GEN AD review of draft-ietf-dnsop-avoid-fragmentation-16

CC @larseggert

Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/VBI2ri6JwD9TEPjcxKBi828dVs4).

## Comments

### Paragraph 2
```
                    IP Fragmentation Avoidance in DNS
```
Title should clarify this is for DNS over UDP.

### Section 1, paragraph 5
```
    This document specifies various techniques to avoid IP fragmentation
    of UDP packets in DNS.
```
Really wish that this BCP made a much stronger recommendation for DNS over TCP.

### Section 3.1, paragraph 0
```
  3.1.  Recommendations for UDP responders
```
I find myself agreeing with other ballots on these recommendations.
Will refrain from duplicating them (and also from holding another DISCUSS
based on them.)

### Section 3.1, paragraph 3
```
    At the time of writing, most DNS server software did not set the DF
    bit for IPv4, and many OS kernel constraints make it difficult to set
    the DF bit in all cases.  Best Current Practice documents should not
    specify what is currently impossible, so R2, which is setting the DF
    bit, is "MAY" rather than "SHOULD".
```
Maybe I'm familiar with different kernels, but all the ones I am
familiar with (except for some IoT platforms) readily offer socket
options to set DF (and prevent stack fragmentation in v6).

### Section 3.1, paragraph 3
```
    R3.  UDP responders SHOULD compose response packets that fit in the
    minimum of the offered requestor's maximum UDP payload size
    [RFC6891], the interface MTU, and the RECOMMENDED maximum DNS/UDP
    payload size 1400.
```
Why SHOULD, i.e., when would it ever be OK to do this? Also, where
does the 1400 byte value come from (magic constant?)

### Section 3.1, paragraph 3
```
    R5.  UDP responders SHOULD limit the response size when UDP
    responders are located on small MTU (<1500) networks.
```
Limit *to what*?

### Section 4, paragraph 0
```
  4.  Recommendations for zone operators and DNS server operators
```
I find it somewhat questionable to recommend changes in how DNS is
being operated just to cater to UDP needing to remain a viable
transport. (I realize I may be an outlier here.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-ietf-dnsop-svcb-https`, but that has been published
as `RFC9460`.

### Grammar/style

#### "Appendix B.", paragraph 3
```
fter two UDP timeouts, BIND 9 will fallback to TCP. C.2. Knot DNS and Knot R
                                  ^^^^^^^^
```
The word "fallback" is a noun. The verb is spelled with a space.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
2024-01-04
16 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2024-01-04
16 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-01-03
16 Murray Kucherawy
[Ballot comment]
I support Rob Wilton's DISCUSS position.  Piling on a bit, in reference to:

  R6.  UDP requestors SHOULD limit the requestor's maximum UDP …
[Ballot comment]
I support Rob Wilton's DISCUSS position.  Piling on a bit, in reference to:

  R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
  size to the RECOMMENDED size of 1400 or a smaller size.

I think the "RECOMMENDED" here is just carrying forward a "RECOMMENDED" from someplace else.  If that's correct, I suggest changing it to "recommended" or, if you want to be more precise, "... to the size recommended by RFCXXXX of 1400 or smaller."  Now it's clear what the SHOULD is referencing, and you don't own the RECOMMENDED part here.

I suggest defining "EMSGSIZE" in Section 2 to be the UNIX error code of the same name.  Otherwise, we encounter it in Section 3.1 in a way that could mean it's an error code (which is how I think you intend it) or as a symbolic name for the path MTU size.

Forwarded comments from Orie Steele, incoming ART Area Director:

"Recommendations for zone operators and DNS server operators"

* Define "large / small" better.

"Protocol compliance considerations"

* Would be nice to see reporting recommendations, perhaps that make the failure an internal cost for the failing component?... would not want a repeat of dmarc though.
2024-01-03
16 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2024-01-03
16 Murray Kucherawy [Ballot discuss]
Please address the point raised by Barry Leiba in his ARTART review.
2024-01-03
16 Murray Kucherawy
[Ballot comment]
I support Rob Wilton's DISCUSS position.  Piling on a bit, in reference to:

  R6.  UDP requestors SHOULD limit the requestor's maximum UDP …
[Ballot comment]
I support Rob Wilton's DISCUSS position.  Piling on a bit, in reference to:

  R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
  size to the RECOMMENDED size of 1400 or a smaller size.

I think the "RECOMMENDED" here is just carrying forward a "RECOMMENDED" from someplace else.  If that's correct, I suggest changing it to "recommended" or, if you want to be more precise, "... to the size recommended by RFCXXXX of 1400 or smaller."  Now it's clear what the SHOULD is referencing, and you don't own the RECOMMENDED part here.

I suggest defining "EMSGSIZE" in Section 2 to be the UNIX error code of the same name.  Otherwise, we encounter it in Section 3.1 in a way that could mean it's an error code (which is how I think you intend it) or as a symbolic name for the path MTU size.
2024-01-03
16 Murray Kucherawy [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy
2024-01-03
16 Roman Danyliw
[Ballot comment]
Thank you to Donald Eastlake for his SECDIR review.  Please review his proposed text on including clarifying language around the applicability of TSIG. …
[Ballot comment]
Thank you to Donald Eastlake for his SECDIR review.  Please review his proposed text on including clarifying language around the applicability of TSIG.

I support Martin Duke and Rob Wilton’s DISCUSS positions.

** Section 7.2
  This would indicate prior
  reliance upon IP fragmentation, which is universally considered to be
  harmful to both the performance and stability of applications,
  endpoints, and gateways.

Is there a reference that can be cited to substantiate this “universal” position?
2024-01-03
16 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-01-03
16 John Scudder [Ballot comment]
I support Rob's DISCUSS position.
2024-01-03
16 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2024-01-02
16 Erik Kline
[Ballot comment]
# Internet AD comments for draft-ietf-dnsop-avoid-fragmentation-16
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments …
[Ballot comment]
# Internet AD comments for draft-ietf-dnsop-avoid-fragmentation-16
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S1

* "TCP avoids fragmentation by ..."

  TCP also benefits hugely from widespread support for MSS rewriting.  If
  something like an "EDNS0 Payload Size rewriting" function was available
  and as widely deployed there might be a very different conversation to
  be had.

  No text changes necessary; just a random thought.
2024-01-02
16 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2024-01-02
16 Martin Duke
[Ballot discuss]
1) I'm unclear about Sec 4, R11 and Appendix B. When configured for minimal response, are responses to ALL requesters reduced in size, …
[Ballot discuss]
1) I'm unclear about Sec 4, R11 and Appendix B. When configured for minimal response, are responses to ALL requesters reduced in size, or only to those requesters that indicate a small MTU?

As DNS becomes a more important vehicle for various discovery protocols (e.g. ECH), I would hate for responders to globally invoke a policy that makes it hard to deploy those protocols. But I'm happy to discuss this.

2) In section 3.2, R8, please add RFC 8961 as a normative reference for how to set the timeout (e.g. "UDP requestors MUST observe [RFC8961] in setting their timeout.")
2024-01-02
16 Martin Duke
[Ballot comment]
Thanks to Mirja Kuhlewind for the TSVART review, and to the authors for responding.

(1) I support Rob's DISCUSS (and Paul's comment) about …
[Ballot comment]
Thanks to Mirja Kuhlewind for the TSVART review, and to the authors for responding.

(1) I support Rob's DISCUSS (and Paul's comment) about SHOULD/MAY. "do it unless the OS makes it impossible" is a typical use of SHOULD.

(2) Section 3.1, R1 says that responders SHOULD omit the fragment header. Under what circumstances would it be reasonable to keep it?
2024-01-02
16 Martin Duke [Ballot Position Update] New position, Discuss, has been recorded for Martin Duke
2024-01-02
16 Robert Wilton
[Ballot discuss]
Hi,

Thanks for this document.

I'm echoing Paul's and the SECDIR review comments here on the use of MAY in recommendations (since everywhere …
[Ballot discuss]
Hi,

Thanks for this document.

I'm echoing Paul's and the SECDIR review comments here on the use of MAY in recommendations (since everywhere you see MAY it is equally valid for an interpretation to treat it as "MAY NOT"), but I think that this makes the document, as a proposed BCP, unclear enough that I'm raising this to level of a DISCUSS.


(1) p 3, sec 3.1.  Recommendations for UDP responders

  At the time of writing, most DNS server software did not set the DF
  bit for IPv4, and many OS kernel constraints make it difficult to set
  the DF bit in all cases.  Best Current Practice documents should not
  specify what is currently impossible, so R2, which is setting the DF
  bit, is "MAY" rather than "SHOULD".


I think that this recommendation, particularly because it is using RFC 2119 language, is unclear.  I would suggest rephasing this to something like:

  R2.  Where supported, UDP responders SHOULD set IP "Don't Fragment
  flag (DF) bit" [RFC0791] on IPv4.


(2) p 3, sec 3.2.  Recommendations for UDP requestors

  R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
  size to the RECOMMENDED size of 1400 or a smaller size.

I find this recommendation to be unclear because it mixes both a "SHOULD" and "RECOMMENDED", i.e., I find it unclear as to what the "SHOULD" applies to.  Is the recommendation (i) that UDP requestors should limit the maximum UDP payload.  Or (ii) is the recommendation that a limit of 1400 be used, or (iii) perhaps both.  Maybe rewording this to something like the following would help:

  R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
  size to 1400 bytes, but MAY limit the maximum UDP payload size to a
  smaller size on small MTU (less than 1500 bytes) networks.

  or,

  R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
  size.  It is RECOMMENDED to use a limit of 1400 bytes, but a smaller
  limit MAY be used.


(3) p 3, sec 3.2.  Recommendations for UDP requestors

  R7.  UDP requestors MAY drop fragmented DNS/UDP responses without IP
  reassembly to avoid cache poisoning attacks.

As written, I don't think that this is really a recommendation.  Either it is a just a statement or fact (in which case it is not a recommendation), or it should be upgraded to a SHOULD.


(4) p 4, sec 3.2.  Recommendations for UDP requestors

  R7.  UDP requestors MAY drop fragmented DNS/UDP responses without IP
  reassembly to avoid cache poisoning attacks.
  R8.  DNS responses may be dropped by IP fragmentation.  Upon a
  timeout, to avoid resolution failures, UDP requestors MAY retry using
  TCP or UDP with a smaller EDNS requestor's maximum UDP payload size
  per local policy.

Again, I think that this document would be clearer if this was a SHOULD rather than a MAY.

Regards,
Rob
2024-01-02
16 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2023-12-29
16 Barry Leiba Request for Telechat review by ARTART Completed: Ready with Nits. Reviewer: Barry Leiba. Sent review to list. Submission of review completed at an earlier date.
2023-12-29
16 Barry Leiba Request for Telechat review by ARTART Completed: Ready with Nits. Reviewer: Barry Leiba.
2023-12-29
16 Paul Wouters
[Ballot comment]

        At the time of writing, most DNS server software did not set
        the DF bit …
[Ballot comment]

        At the time of writing, most DNS server software did not set
        the DF bit for IPv4, and many OS kernel constraints make it
        difficult to set the DF bit in all cases. Best Current Practice
        documents should not specify what is currently impossible, so R2,
        which is setting the DF bit, is "MAY" rather than "SHOULD".

If what you want is "we really really want this but it cannot be done on every OS",
then I think SHOULD instead of MUST is fine, but MAY seems too weak.

        R7. UDP requestors MAY drop fragmented DNS/UDP responses without
        IP reassembly to avoid cache poisoning attacks.

        R8. DNS responses may be dropped by IP fragmentation. Upon a
        timeout, to avoid resolution failures, UDP requestors MAY retry
        using TCP or UDP with a smaller EDNS requestor's maximum UDP
        payload size per local policy.

Same here. R7 and R8 are "recommendations" so I feel the MAY's should be SHOULDs.
Otherwise the recommendation becomes "do whatever you MAY please", in which case
why are these in the document?


        R9. Use a smaller number of name servers (13 may be too large)

I would say "name server names" instead of "name servers", to avoid any ambiguity
of anycast name servers operating under the same name. Eg the document is not
saying "use less than 13 name servers", but it is saying "use less than 13 name
server names"


        smaller than those usually used for RSA.

smaller than those of equivalent cryptographic strength using RSA
2023-12-29
16 Paul Wouters [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters
2023-12-27
16 Donald Eastlake Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Donald Eastlake. Submission of review completed at an earlier date.
2023-12-27
16 Donald Eastlake Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Donald Eastlake.
2023-12-27
16 Vladimír Čunát Request for Telechat review by DNSDIR Completed: Ready. Reviewer: Vladimír Čunát. Sent review to list.
2023-12-26
16 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2023-12-23
16 Tero Kivinen Request for Telechat review by SECDIR is assigned to Donald Eastlake
2023-12-20
16 Barry Leiba Request for Telechat review by ARTART is assigned to Barry Leiba
2023-12-20
16 Jim Reid Request for Telechat review by DNSDIR is assigned to Vladimír Čunát
2023-12-19
16 Cindy Morgan Placed on agenda for telechat - 2024-01-04
2023-12-18
16 Warren Kumari Ballot has been issued
2023-12-18
16 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2023-12-18
16 Warren Kumari Created "Approve" ballot
2023-12-18
16 (System) Changed action holders to Warren Kumari (IESG state changed)
2023-12-18
16 Warren Kumari IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2023-12-18
16 Warren Kumari Ballot writeup was changed
2023-12-12
16 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2023-12-12
16 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-16.txt
2023-12-12
16 (System) New version approved
2023-12-12
16 (System) Request for posting confirmation emailed to previous authors: Kazunori Fujiwara , Paul Vixie
2023-12-12
16 Kazunori Fujiwara Uploaded new revision
2023-12-11
15 Warren Kumari Changed action holders to Paul Vixie, Kazunori Fujiwara (Dec 4th - Waiting on authors.)
2023-10-28
15 Donald Eastlake Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Donald Eastlake.
2023-10-27
15 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2023-10-24
15 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2023-10-24
15 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnsop-avoid-fragmentation-15, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnsop-avoid-fragmentation-15, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2023-10-23
15 Barry Leiba Request for Last Call review by ARTART Completed: Ready with Issues. Reviewer: Barry Leiba. Sent review to list.
2023-10-23
15 Christer Holmberg Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Christer Holmberg. Sent review to list.
2023-10-22
15 Mirja Kühlewind Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Mirja Kühlewind. Sent review to list.
2023-10-19
15 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2023-10-19
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2023-10-19
15 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2023-10-17
15 Magnus Westerlund Request for Last Call review by TSVART is assigned to Mirja Kühlewind
2023-10-16
15 Barry Leiba Request for Last Call review by ARTART is assigned to Barry Leiba
2023-10-14
15 Vladimír Čunát Request for Last Call review by DNSDIR Completed: Ready. Reviewer: Vladimír Čunát. Sent review to list.
2023-10-13
15 Jim Reid Request for Last Call review by DNSDIR is assigned to Vladimír Čunát
2023-10-13
15 Cindy Morgan IANA Review state changed to IANA - Review Needed
2023-10-13
15 Cindy Morgan
The following Last Call announcement was sent out (ends 2023-10-27):

From: The IESG
To: IETF-Announce
CC: benno@NLnetLabs.nl, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-avoid-fragmentation@ietf.org, swoolf@pir.org …
The following Last Call announcement was sent out (ends 2023-10-27):

From: The IESG
To: IETF-Announce
CC: benno@NLnetLabs.nl, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-avoid-fragmentation@ietf.org, swoolf@pir.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Fragmentation Avoidance in DNS) to Best Current Practice


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Fragmentation Avoidance in DNS'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-10-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes techniques to
  avoid IP fragmentation in DNS.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8899: Packetization Layer Path MTU Discovery for Datagram Transports (Proposed Standard - Internet Engineering Task Force (IETF))



2023-10-13
15 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2023-10-13
15 Warren Kumari Last call was requested
2023-10-13
15 Warren Kumari Last call announcement was generated
2023-10-13
15 Warren Kumari Ballot approval text was generated
2023-10-13
15 Warren Kumari IESG state changed to Last Call Requested from Publication Requested
2023-10-10
15 Tim Wicinski



(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send …



(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes to avoid IP
  fragmentation in DNS.

Working Group Summary:

The working group had a few issues to work through, which included adding an
appendix for implementations. Several comments came in after WGLC, but they
were very relevant, so the working group addressed them.
There are currently no issues and solid consensus with the final document.

Document Quality:

Document is of good quality.

Personnel:

Document Shepherd is Tim Wicinski

Responsible Area Director is Warren Kumari

(3) Document Shepherd did an editorial review, as a detailed technical review.
    Document is ready.

(4) Document Shepherd has no concerns over quality of review


(5) No broader review needed

(6) Document Shepherd does not have any concerns.


(7) All authors confirm no IPR

(8) No IPR

(9) WG Consensus is solid.

(10) No Appeals threatened

(11) No nits

(12) No formal reviews needed

(13) all references identified correctly.

(14) All normative references are ready.

(15) No downward normative references

(16) No existing RFCs will be updated.

(17) No IANA

(18) No IANA

(19) N/A

(20) No Yang
2023-10-10
15 Tim Wicinski IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2023-10-10
15 Tim Wicinski IESG state changed to Publication Requested from AD is watching
2023-10-10
15 Tim Wicinski



(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send …



(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes to avoid IP
  fragmentation in DNS.

Working Group Summary:

The working group had a few issues to work through, which included adding an
appendix for implementations. Several comments came in after WGLC, but they
were very relevant, so the working group addressed them.
There are currently no issues and solid consensus with the final document.

Document Quality:

Document is of good quality.

Personnel:

Document Shepherd is Tim Wicinski

Responsible Area Director is Warren Kumari

(3) Document Shepherd did an editorial review, as a detailed technical review.
    Document is ready.

(4) Document Shepherd has no concerns over quality of review


(5) No broader review needed

(6) Document Shepherd does not have any concerns.


(7) All authors confirm no IPR

(8) No IPR

(9) WG Consensus is solid.

(10) No Appeals threatened

(11) No nits

(12) No formal reviews needed

(13) all references identified correctly.

(14) All normative references are ready.

(15) No downward normative references

(16) No existing RFCs will be updated.

(17) No IANA

(18) No IANA

(19) N/A

(20) No Yang
2023-10-10
15 Tim Wicinski IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2023-09-19
15 Tim Wicinski IETF WG state changed to In WG Last Call from WG Document
2023-09-14
15 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-15.txt
2023-09-14
15 (System) New version approved
2023-09-14
15 (System) Request for posting confirmation emailed to previous authors: Kazunori Fujiwara , Paul Vixie
2023-09-14
15 Kazunori Fujiwara Uploaded new revision
2023-08-25
14 Warren Kumari IETF WG state changed to WG Document from Submitted to IESG for Publication
2023-08-25
14 Warren Kumari IESG state changed to AD is watching from AD Evaluation
2023-08-21
14 Warren Kumari IESG state changed to AD Evaluation from Publication Requested
2023-08-21
14 Warren Kumari Ballot writeup was changed
2023-08-21
14 Warren Kumari Ballot writeup was changed
2023-08-16
14 Tim Wicinski



(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send …



(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes to avoid IP
  fragmentation in DNS.

Working Group Summary:

The working group had a few issues to work through, which included adding an
appendix for implementations. Several comments came in after WGLC, but they
were very relevant, so the working group addressed them.
There are currently no issues and solid consensus with the final document.

Document Quality:

Document is of good quality.

Personnel:

Document Shepherd is Tim Wicinski

Responsible Area Director is Warren Kumari

(3) Document Shepherd did an editorial review, as a detailed technical review.
    Document is ready.

(4) Document Shepherd has no concerns over quality of review


(5) No broader review needed

(6) Document Shepherd does not have any concerns.


(7) All authors confirm no IPR

(8) No IPR

(9) WG Consensus is solid.

(10) No Appeals threatened

(11) No nits

(12) No formal reviews needed

(13) all references identified correctly.

(14) All normative references are ready.

(15) No downward normative references

(16) No existing RFCs will be updated.

(17) No IANA

(18) No IANA

(19) N/A

(20) No Yang
2023-08-16
14 Tim Wicinski IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2023-08-16
14 Tim Wicinski IESG state changed to Publication Requested from I-D Exists
2023-08-16
14 Tim Wicinski Document is now in IESG state Publication Requested
2023-08-16
14 Tim Wicinski



(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send …



(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes to avoid IP
  fragmentation in DNS.

Working Group Summary:

The working group had a few issues to work through, which included adding an
appendix for implementations. Several comments came in after WGLC, but they
were very relevant, so the working group addressed them.
There are currently no issues and solid consensus with the final document.

Document Quality:

Document is of good quality.

Personnel:

Document Shepherd is Tim Wicinski

Responsible Area Director is Warren Kumari

(3) Document Shepherd did an editorial review, as a detailed technical review.
    Document is ready.

(4) Document Shepherd has no concerns over quality of review


(5) No broader review needed

(6) Document Shepherd does not have any concerns.


(7) All authors confirm no IPR

(8) No IPR

(9) WG Consensus is solid.

(10) No Appeals threatened

(11) No nits

(12) No formal reviews needed

(13) all references identified correctly.

(14) All normative references are ready.

(15) No downward normative references

(16) No existing RFCs will be updated.

(17) No IANA

(18) No IANA

(19) N/A

(20) No Yang
2023-07-10
14 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-14.txt
2023-07-10
14 Kazunori Fujiwara New version accepted (logged-in submitter: Kazunori Fujiwara)
2023-07-10
14 Kazunori Fujiwara Uploaded new revision
2023-07-07
13 Vladimír Čunát Request for Last Call review by DNSDIR Completed: Ready. Reviewer: Vladimír Čunát. Sent review to list.
2023-07-05
13 Tim Wicinski Tag Revised I-D Needed - Issue raised by WG cleared.
2023-07-05
13 Jim Reid Request for Last Call review by DNSDIR is assigned to Vladimír Čunát
2023-07-05
13 Tim Wicinski Requested Last Call review by DNSDIR
2023-07-05
13 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-13.txt
2023-07-05
13 Kazunori Fujiwara New version approved
2023-07-05
13 (System) Request for posting confirmation emailed to previous authors: Kazunori Fujiwara , Paul Vixie
2023-07-05
13 Kazunori Fujiwara Uploaded new revision
2023-03-29
12 Tim Wicinski
Implementers raised discussion points over which guidance will be addressed.
Suggestion from chairs to add an implementation appendix to document this.
Will need some WG …
Implementers raised discussion points over which guidance will be addressed.
Suggestion from chairs to add an implementation appendix to document this.
Will need some WG consensus
2023-03-29
12 Tim Wicinski Tag Revised I-D Needed - Issue raised by WG set. Tag Other - see Comment Log cleared.
2023-03-29
12 Tim Wicinski IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Document
2023-03-29
12 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-12.txt
2023-03-29
12 Kazunori Fujiwara New version approved
2023-03-29
12 (System) Request for posting confirmation emailed to previous authors: Kazunori Fujiwara , Paul Vixie
2023-03-29
12 Kazunori Fujiwara Uploaded new revision
2023-02-03
11 Warren Kumari
[ Note: Process / tooling wonkery ahead... ]

I returned the document to the DNSOP WG on Jan 24 2023. This cleared the "IESG State" …
[ Note: Process / tooling wonkery ahead... ]

I returned the document to the DNSOP WG on Jan 24 2023. This cleared the "IESG State" field in the datatracker, but did not reset the "WG State" and so the document shows up in a weird state in the Datatracker. This change is purely administrative to make the states align.
2023-02-03
11 Warren Kumari Tag Other - see Comment Log set.
2023-02-03
11 Warren Kumari IETF WG state changed to WG Document from Submitted to IESG for Publication
2023-01-24
11 Warren Kumari
See: https://mailarchive.ietf.org/arch/msg/dnsop/x_639OElsGSG5Gz10YrB80xS6Fg/

This thread expressed desire to have an implementation section, and the authors concurred. Chairs requested that document be returned to the WG for …
See: https://mailarchive.ietf.org/arch/msg/dnsop/x_639OElsGSG5Gz10YrB80xS6Fg/

This thread expressed desire to have an implementation section, and the authors concurred. Chairs requested that document be returned to the WG for this to happen.
2023-01-24
11 (System) Changed action holders to Warren Kumari (IESG state changed)
2023-01-24
11 Warren Kumari IESG state changed to I-D Exists from Publication Requested
2023-01-20
11 Warren Kumari Ballot writeup was changed
2023-01-19
11 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-11.txt
2023-01-19
11 (System) New version approved
2023-01-19
11 (System) Request for posting confirmation emailed to previous authors: Kazunori Fujiwara , Paul Vixie , dnsop-chairs@ietf.org
2023-01-19
11 Kazunori Fujiwara Uploaded new revision
2022-12-21
10 Tim Wicinski


(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send …


(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes to avoid IP
  fragmentation in DNS.

Working Group Summary:

The working group had a few issues to work through, but there no issues and
solid consensus with the final document.

Document Quality:

Document is of good quality.

Personnel:

Document Shepherd is Tim Wicinski

Responsible Area Director is Warren Kumari

(3) Document Shepherd did an editorial review, as a detailed technical review.
    Document is ready.

(4) Document Shepherd has no concerns over quality of review

(5) No broader review needed

(6) Document Shepherd has not concerns.

(7) All authors confirm no IPR

(8) No IPR

(9) WG Consensus is solid.

(10) No Appeals threatened

(11) No nits

(12) No formal reviews needed

(13) all references identified correctly.

(14) All normative references are ready.

(15) No downward normative references

(16) No existing RFCs will be updated.

(17) No IANA

(18) No IANA

(19) N/A

(20) No Yang
2022-12-21
10 Tim Wicinski Responsible AD changed to Warren Kumari
2022-12-21
10 Tim Wicinski IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2022-12-21
10 Tim Wicinski IESG state changed to Publication Requested from I-D Exists
2022-12-21
10 Tim Wicinski Document is now in IESG state Publication Requested
2022-12-21
10 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-10.txt
2022-12-21
10 Kazunori Fujiwara New version accepted (logged-in submitter: Kazunori Fujiwara)
2022-12-21
10 Kazunori Fujiwara Uploaded new revision
2022-12-21
09 Tim Wicinski Notification list changed to benno@NLnetLabs.nl, swoolf@pir.org, tjw.ietf@gmail.com from benno@NLnetLabs.nl, swoolf@pir.org because the document shepherd was set
2022-12-21
09 Tim Wicinski Document shepherd changed to Tim Wicinski
2022-12-20
09 Tim Wicinski


(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send …


(1) RFC is Best Current Practice, and this is the proper type of RFC

(2)

Technical Summary:

  EDNS0 enables a DNS server to send large responses using UDP and is
  widely deployed.  Large DNS/UDP responses are fragmented, and IP
  fragmentation has exposed weaknesses in application protocols.  It is
  possible to avoid IP fragmentation in DNS by limiting response size
  where possible, and signaling the need to upgrade from UDP to TCP
  transport where necessary.  This document proposes to avoid IP
  fragmentation in DNS.

Working Group Summary:

The working group had a few issues to work through, but there no issues and
solid consensus with the final document.

Document Quality:

Document is of good quality.

Personnel:

Document Shepherd is Tim Wicinski

Responsible Area Director is Warren Kumari

(3) Document Shepherd did an editorial review, as a detailed technical review.
    Document is ready.

(4) Document Shepherd has no concerns over quality of review

(5) No broader review needed

(6) Document Shepherd has not concerns.

(7) All authors confirm no IPR

(8) No IPR

(9) WG Consensus is solid.

(10) No Appeals threatened

(11) No nits

(12) No formal reviews needed

(13) all references identified correctly.

(14) All normative references are ready.

(15) No downward normative references

(16) No existing RFCs will be updated.

(17) No IANA

(18) No IANA

(19) N/A

(20) No Yang
2022-12-08
09 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-09.txt
2022-12-08
09 (System) New version approved
2022-12-08
09 (System) Request for posting confirmation emailed to previous authors: Kazunori Fujiwara , Paul Vixie , dnsop-chairs@ietf.org
2022-12-08
09 Kazunori Fujiwara Uploaded new revision
2022-10-22
08 Benno Overeinder IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Consensus: Waiting for Write-Up
2022-10-13
08 Tim Wicinski IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2022-08-21
08 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-08.txt
2022-08-21
08 (System) New version approved
2022-08-21
08 (System) Request for posting confirmation emailed to previous authors: Kazunori Fujiwara , Paul Vixie
2022-08-21
08 Kazunori Fujiwara Uploaded new revision
2022-07-27
07 Tim Wicinski IETF WG state changed to In WG Last Call from WG Document
2022-07-27
07 Tim Wicinski Changed consensus to Yes from Unknown
2022-07-27
07 Tim Wicinski Intended Status changed to Best Current Practice from None
2022-07-03
07 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-07.txt
2022-07-03
07 (System) New version approved
2022-07-03
07 (System) Request for posting confirmation emailed to previous authors: Kazunori Fujiwara , Paul Vixie
2022-07-03
07 Kazunori Fujiwara Uploaded new revision
2022-06-26
06 (System) Document has expired
2022-04-26
06 Benno Overeinder Notification list changed to benno@NLnetLabs.nl, swoolf@pir.org from benno@NLnetLabs.nl because the document shepherd was set
2022-04-26
06 Benno Overeinder Document shepherd changed to Suzanne Woolf
2021-12-23
06 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-06.txt
2021-12-23
06 (System) New version approved
2021-12-23
06 (System) Request for posting confirmation emailed to previous authors: Kazunori Fujiwara , Paul Vixie , dnsop-chairs@ietf.org
2021-12-23
06 Kazunori Fujiwara Uploaded new revision
2021-09-03
05 Benno Overeinder Added to session: interim-2021-dnsop-01
2021-09-03
05 Benno Overeinder Notification list changed to benno@NLnetLabs.nl because the document shepherd was set
2021-09-03
05 Benno Overeinder Document shepherd changed to Benno Overeinder
2021-07-26
05 Benno Overeinder Added to session: IETF-111: dnsop  Mon-1600
2021-06-23
05 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-05.txt
2021-06-23
05 (System) New version approved
2021-06-23
05 (System) Request for posting confirmation emailed to previous authors: Kazunori Fujiwara , Paul Vixie
2021-06-23
05 Kazunori Fujiwara Uploaded new revision
2021-03-05
04 Benno Overeinder Added to session: IETF-110: dnsop  Thu-1700
2021-02-22
04 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-04.txt
2021-02-22
04 (System) New version approved
2021-02-22
04 (System) Request for posting confirmation emailed to previous authors: Kazunori Fujiwara , Paul Vixie
2021-02-22
04 Kazunori Fujiwara Uploaded new revision
2020-11-23
03 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-03.txt
2020-11-23
03 (System) New version approved
2020-11-23
03 (System) Request for posting confirmation emailed to previous authors: Kazunori Fujiwara , Paul Vixie
2020-11-23
03 Kazunori Fujiwara Uploaded new revision
2020-11-19
02 Tim Wicinski Added to session: IETF-109: dnsop  Tue-1200
2020-09-15
02 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-02.txt
2020-09-15
02 (System) New version approved
2020-09-15
02 (System) Request for posting confirmation emailed to previous authors: Paul Vixie , Kazunori Fujiwara
2020-09-15
02 Kazunori Fujiwara Uploaded new revision
2020-07-27
01 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-01.txt
2020-07-27
01 (System) New version approved
2020-07-27
01 (System) Request for posting confirmation emailed to previous authors: Paul Vixie , Kazunori Fujiwara
2020-07-27
01 Kazunori Fujiwara Uploaded new revision
2020-07-22
00 Tim Wicinski Added to session: IETF-108: dnsop  Wed-1100
2020-06-30
00 Tim Wicinski This document now replaces draft-fujiwara-dnsop-avoid-fragmentation instead of None
2020-06-30
00 Kazunori Fujiwara New version available: draft-ietf-dnsop-avoid-fragmentation-00.txt
2020-06-30
00 (System) WG -00 approved
2020-06-30
00 Kazunori Fujiwara Set submitter to "Kazunori Fujiwara ", replaces to draft-fujiwara-dnsop-avoid-fragmentation and sent approval email to group chairs: dnsop-chairs@ietf.org
2020-06-30
00 Kazunori Fujiwara Uploaded new revision