Subject: [dnsext] draft-levine-dnsextlang-02

From: "John Levine" <[email-masked]>
Date: 4 Dec 2011 07:47:10 -0000

Last month I sent in this draft which specifies an extension language
for DNS master files, to make it easier to define new RR types without
having to add new code to DNS servers every time.

I think I saw some interest.  Assuming dnsext shuts down, where would
be a reasonable place to work on it?

R's,
John

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: David Conrad <[email-masked]>
Date: Sun, 4 Dec 2011 07:42:59 -0800

> be a reasonable place to work on it?

Well, you could hold a BOF and if there is sufficient interest, spin up a DNSLANG (or whatever) working group...

Regards,
-drc

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 4 Dec 2011 08:17:49 -0800

> Well, you could hold a BOF and if there is sufficient interest, spin up a DNSLANG (or whatever) working group...

Alternately, you could just keep discussing it on this list (which Ralph said would remain alive) until Ralph thought the draft was mature enough for an Individual Submission.

There is no IETF process rule that says an out-of-charter idea needs to have any face-to-face BoF, nor any WG. In fact, the process is quite clear that the opposite is true.

--Paul Hoffman

---

From: David Conrad <[email-masked]>
Date: Sun, 4 Dec 2011 08:26:27 -0800

> Alternately, you could just keep discussing it on this list (which Ralph said would remain alive) until Ralph thought the draft was mature enough for an Individual Submission.

Sure. I'll admit I'm unclear as to when something is deemed WG-worthy (I thought that was the point of a BoF, but apparently I am mistaken).

> There is no IETF process rule that says an out-of-charter idea needs to have any face-to-face BoF ...

If DNSEXT were to be shut down, there would no longer be a charter to be out-of.

Regards,
-drc

---

From: "John R. Levine" <[email-masked]>
Date: 4 Dec 2011 10:40:54 -0800

> Well, you could hold a BOF and if there is sufficient interest, spin up a DNSLANG (or whatever) working group...

Assuming I can figure out how to pay my way to Paris, sounds like a plan.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 4 Dec 2011 11:13:38 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Saturday, December 03, 2011 11:47 PM
> To: [email-masked]
> Subject: [dnsext] draft-levine-dnsextlang-02
> 

If you're adverse to doing individual submissions, you could try OPSAWG.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 4 Dec 2011 11:21:54 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Sunday, December 04, 2011 11:14 AM
> To: [email-masked]
> Subject: Re: [dnsext] draft-levine-dnsextlang-02
> 

Sorry, dnsext is in INT, so that should be the INTAREA working group.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 04 Dec 2011 16:46:05 -0500

Any reason you think this can not be finished in the next 3 months ?

	Olafur

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 4 Dec 2011 14:24:50 -0800

> Any reason you think this can not be finished in the next 3 months ?

What in the history of the efficiency of this WG for the past few years makes you think it could be?

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Mon, 05 Dec 2011 10:01:52 +1100

On a similar matter I was in the process of submitting the following.
I just needed to address internal comments.  I also think my EDNS
expire option still needs to be addressed though I suspect I'll do that
as a individual submission.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

                                                              M. Andrews
Internet-Draft                                                       ISC
Intended status: Standards Track                        November 4, 2011
Expires: May 7, 2012

                       DNS and UDP Fragmentation
                draft-andrews-dnsext-udp-fragmentation.

Abstract

   This document provides advice to DNS developers about sending DNS UDP
   messages and Path MTU Discovery.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 7, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Andrews                    Expires May 7, 2012                  [Page 1]

Internet-Draft          DNS and UDP Fragmentation          November 2011

Table of Contents

   1.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Reserved Words  . . . . . . . . . . . . . . . . . . . . . . 3
   2.  IPv4 and Fragmentation  . . . . . . . . . . . . . . . . . . . . 3
   3.  IPv6 and Fragmentation  . . . . . . . . . . . . . . . . . . . . 3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 4

Andrews                    Expires May 7, 2012                  [Page 2]

Internet-Draft          DNS and UDP Fragmentation          November 2011

1.  Background

   IPv6 has changed the dynamics of UDP, Path MTU Discovery (PMTUD) and
   IP fragmentation.  With IPv4 DNS/UDP packets were fragmented by the
   network and no PMTUD was performed.  With IPv6 fragmentation occurs
   in the sending node and PMTUD is alway performed unless the IPv6
   packet is fragmented by the sending node using the network MTU.

   DNS/UDP does not work well when PMTUD discover is performed.  If the
   Packet Too Big / Need Fragmentation ICMP messages are not received
   there is no feedback path in DNS to reduce the size of the fragments
   like there is with TCP.

   This document recommends that all DNS/UDP messages are sent such that
   they do not trigger PMTUD.

1.1.  Reserved Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

2.  IPv4 and Fragmentation

   There are a number of IP stacks that enable PMTUD for all IP packets
   by default against the advice of [RFC 1191].  On those IP stacks it
   is necessary for the application to disable PMTUD on a per socket/
   packet basis or for the operator to disable it globally if there is
   no per socket/packet control.

3.  IPv6 and Fragmentation

   It was realised that IPv6 changed the way PMTUD happened and that
   there were application, like DNS, that did not work well with PMTUD.
   For those applications a socket option called IPV6_USE_MIN_MTU was
   developed [RFC 3542].  It is RECOMMENDED that this option be set to 1
   (one) when sending DNS/UDP messages over IPv6.  This option can be
   set at the socket level or it can be set on a per UDP datagram basis.

   If the IPv6 stack does not support IPV6_USE_MIN_MTU steps should be
   taken to prevent PMTUD occuring.  These include, but are not limited
   to, setting the interface the packets are being sent over should be
   set to the network MTU (1280 bytes) or restricing DNS/UDP packets to
   no more than 1280 bytes including IPv6 headers.

Andrews                    Expires May 7, 2012                  [Page 3]

Internet-Draft          DNS and UDP Fragmentation          November 2011

4.  IANA Considerations

   No IANA Considerations.

5.  Security Considerations

   Failure to prevent PMTUD discovery can lead to denial of service for
   DNS clients.

   Firewalls are often configured to block fragmented IP packets as
   early IP stacks had fragmentation re-assembly bugs.  These bugs were
   exploited to perform a number of denial of service attacks cira 1999.

   Such blocks should be relaxed to permit fragmented UDP packets.

6.  Normative References

   [RFC 1191]
              Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
              November 1990.

   [RFC 2119]
              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC 3542]
              Stevens, W., Thomas, M., Normark, E., and T. Jinmei,
              "Advanced Sockets Application Program Interface (API) for
              IPv6", RFC 2003, May 2003.

Author's Address

   Mark P. Andrews
   Internet Systems Consortium
   950 Charter Street
   Redwood City, CA  94063
   US

   Email: [email-masked]

Andrews                    Expires May 7, 2012                  [Page 4]

---

From: David Conrad <[email-masked]>
Date: Sun, 4 Dec 2011 15:11:08 -0800

Mark,

>                draft-andrews-dnsext-udp-fragmentation.

Wouldn't this be appropriate for DNSOP?

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Mon, 05 Dec 2011 10:34:18 +1100

In message <[email-masked]>, David Conrad
> Wouldn't this be appropriate for DNSOP?

No.  It should be code not configuration.

Mark

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Sun, 4 Dec 2011 21:49:30 -0700

Hi Mark,

You can get blocked ICMP 'packet too big' even if you have the MTU set
to 1280. 

RFC 2460:
In response to an IPv6 packet that is sent to an IPv4 destination (i.e.,
a packet that undergoes translation from IPv6 
to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big
message reporting a Next-Hop MTU less than 1280. 
In that case, the IPv6 node is not required to reduce the size of
subsequent packets to less than 1280, but must include 
a Fragment header in those packets so that the IPv6-to-IPv4 translating
router can obtain a suitable Identification 
value to use in resulting IPv4 fragments. Note that this means the
payload may have to be reduced to 1232 octets (1280 
minus 40 for the IPv6 header and 8 for the Fragment header), and smaller
still if additional extension headers are used.

/Stephan

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Mark Andrews
> Sent: Sunday, December 04, 2011 6:02 PM
> To: Paul Hoffman
> Cc: [email-masked]; Olafur Gudmundsson

---

From: Mark Andrews <[email-masked]>
Date: Mon, 05 Dec 2011 16:24:36 +1100

In message <[email-masked]>, "Ste
phan Lagerholm" writes:
> to 1280.=20
> a packet that undergoes translation from IPv6=20
> message reporting a Next-Hop MTU less than 1280.=20
> subsequent packets to less than 1280, but must include=20
> router can obtain a suitable Identification=20
> payload may have to be reduced to 1232 octets (1280=20

Which just mean that 6man needs to extend the IPv6 socket API so
that the insertion of a fragment header can be signaled.  Or
IPV6_USE_MIN_MTU=1 needs to imply that a fragment header needs to
be added to packets that are not fragmented.  Currently IPV6_USE_MIN_MTU
doesn't quite fully disable PMTUD.

RFC 3542 allows you to turn off adding the adding of Fragment headr
by there is no mechanism to force the adding of a Fragment header.

> >=20
> >=20