Subject: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt

From: Davey Song <[email-masked]>
Date: Mon, 11 Sep 2017 12:29:20 +0800

Hi folks,

I just submit a draft dealing with issue of large DNS response especially
in IPv6. Commnets are welcome.

If chairs think it is in the scope of dnsop wg and encourage us to discuss
it in this mailing list, I can submit it as a draft listed in dnsop wg.

Davey

---------- Forwarded message ----------
From: <[email-masked]>
Date: 11 September 2017 at 10:13
Subject: I-D Action: draft-song-atr-large-resp-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : ATR: Additional Truncated Response for Large DNS
Response
        Author          : Linjian Song
        Filename        : draft-song-atr-large-resp-00.txt
        Pages           : 8
        Date            : 2017-09-10

Abstract:
   As the increasing use of DNSSEC and IPv6, there are more public
   evidence and concerns on IPv6 fragmentation issues due to larger DNS
   payloads over IPv6.  This memo introduces an simple improvement on
   authoritative server by replying additional truncated response just
   after the normal large response.

   REMOVE BEFORE PUBLICATION: The source of the document with test
   script is currently placed at GitHub [ATR-Github].  Comments and pull
   request are welcome.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-song-atr-large-resp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-song-atr-large-resp-00
https://datatracker.ietf.org/doc/html/draft-song-atr-large-resp-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Paul Vixie <[email-masked]>
Date: Sun, 10 Sep 2017 23:11:40 -0700

Davey Song wrote:
> Hi folks,
>
> I just submit a draft dealing with issue of large DNS response
> especially in IPv6. [Comments] are welcome.

in the original EDNS I-D, the following text was present:

> .IP MD
> ``More data'' flag.  Valid only in TCP streams where message ordering and
> reliability are guaranteed.  This flag indicates that the current message is
> not the complete request or response, and should be aggregated with the
> following message(s) before being considered complete.  Such messages are
> called ``segmented.''  It is an error for the RCODE (including the
> EXTENDED-RCODE), AA flag, or DNS Message ID to differ among segments of a
> segmented message.  It is an error for TC to be set on any message of a
> segmented message.  Any given RR must fit completely within a message, and
> all messages will both begin and end on RR boundaries.  Each section in a
> multipart message must appear in normal message order, and each section
> must be complete before later sections are added.  All segments of a message
> must be transmitted contiguously, without interleaving of other messages.

the MD extended flag was removed due to its complexity in 1998 or so, 
and while i planned to re-introduce it in EDNS2, however, EDNS1 never 
made it out the door, so it was lost.

i did not make it possible to use it in UDP because of packet reordering 
and because of microburst problems -- which is to say, TCP delivers 
things in the order they were transmitted, and attempts to avoid 
overloading the path bandwidth-delay-product (BDP) in ways that cause 
congestive loss.

by implication, MD was intended to allow messages larger than 64K 
octets, even while requiring individual RRsets to remain atomic within 
64K octet message segments. i realize that this is not the same goal 
you're pursuing with your draft, but this history may help you.

> If chairs think it is in the scope of dnsop wg and encourage us to
> discuss it in this mailing list, I can submit it as a draft listed in
> dnsop wg.

my own view is that changing the DNS protocol to work around middle 
boxes is a losing game. if measurement shows that a large fraction of 
today's deployed IPv6 edge does not accept extension headers or ICMP, 
and if that means fragmentation will not work toward those edges, then 
our proper response is to change all DNS servers to send extension 
headers on every IPv6 response. force the failures to occur as close as 
possible to, and as early as possible after, they are caused.

separately, we should be working on TFO deployment, and DNS-over-QUIC. 
we need a vision, rather than a long series of easy complications.

-- 
P Vixie

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 12 Sep 2017 09:50:37 +0000

Hi Davey,

ATR make Authoritative Servers send normal big response packet before they
try to send TC response for large RRsets ?

Davey Song <[email-masked]>于2017年9月11日周一 下午12:29写道：

> Internet-Draft
> <https://www.ietf.org/mailman/listinfo/i-d-announce%0DInternet-Draft>
> directories: http://www.ietf.org/shadow.html
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Sep 2017 17:06:59 +0200

On Tue, Sep 12, 2017 at 09:50:37AM +0000,
 Lanlan Pan <[email-masked]> wrote 
 a message of 210 lines which said:

> ATR make Authoritative Servers send normal big response packet
> before they try to send TC response for large RRsets ?

Yes, section 3. "it is suggested a timer to delay the second truncated
response to around 10 millisecond which can be configured by local
operation". (In the spirit of RFC 6555.)

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Sep 2017 08:14:30 -0700

Stephane Bortzmeyer wrote:
>   Lanlan Pan<[email-masked]>  wrote

noting, 10ms isn't enough. packet reordering due to multipath load 
balancing has been observed as high as 60ms due to "buffer bloat".

-- 
P Vixie

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 12 Sep 2017 16:53:48 GMT

> From: Paul Vixie <[email-masked]>
> To: Stephane Bortzmeyer <[email-masked]>

> balancing has been observed as high as 60ms due to "buffer bloat".

I've fought consistent 5 second delays from 'buffer bloat', albeit
20+ years ago at 56K and T1 speeds with Cisco routers on a private IP
world wide network.  A route change in the midst of such delays, whether
from load balancing or anything else, would re-order packets unless
they are delayed by the worst case buffering delay.
We've probably all also seen other cases where an individual IP packet
in a stream (e.g. ICMP/IP) has been or or less mysteriously delayed
by seconds.

At the other extreme, if 10 or 60 ms is good enough in late 2017, might
it be too conservative in 2027?

In other words, it sounds undesirable to write such constants into
any standard unless absolutely necessary.

The delays in section 5.5 of RFC 6555 seem to differ.  They are at
least as much about what humans notice ("humn factors" in RFC 6555)
as network delays; 150-250 ms is about the threshold for what people
consider "sluggish."  150-250 ms also is vastly longer than 10 ms., and
long compared to network delays even in 2012.

Vernon Schryver    [email-masked]

---

From: Davey Song(宋林健) <[email-masked]>
Date: Wed, 13 Sep 2017 17:55:46 +0800

> ATR make Authoritative Servers send normal big response packet before they try to send TC response for large RRsets ? 

No. big response packet first, then TC response.

Davey

---

From: Davey Song(宋林健) <[email-masked]>
Date: Wed, 13 Sep 2017 17:58:05 +0800

Sorry, You are right.

> -----邮件原件-----
> 发件人: Davey Song(宋林健) [mailto:[email-masked]]
> 发送时间: 2017年9月13日 17:56
> 收件人: 'Lanlan Pan'; 'Davey Song'
> 抄送: 'dnsop'
> 主题: 答复: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt
> 
>

---

From: Lanlan Pan <[email-masked]>
Date: Thu, 14 Sep 2017 04:18:33 +0000

> > operation". (In the spirit of RFC 6555.)

Thanks Stephane,  got it, :-)

> balancing has been observed as high as 60ms due to "buffer bloat".

TC may be a safer choice for recursive nowadays ?

致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: william manning <[email-masked]>
Date: Wed, 20 Sep 2017 10:29:42 -0700

i think this is a worthy document for consideration.

/Wm

On Sun, Sep 10, 2017 at 9:29 PM, Davey Song <[email-masked]> wrote:

> <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>

---

From: Davey Song(宋林健) <[email-masked]>
Date: Thu, 21 Sep 2017 11:22:16 +0800

Thank you. 

The large DNS response in IPv6 is a real problem. ATR is one option to adopted in authoritative  server alone. If someone or party have more influence on both resolver and authoritative side (cloud and app provider who can choose their own DNS resolution path),  Mukund’s proposal to fragment the DNS message is a good solution.   https://tools.ietf.org/html/draft-muks-dns-message-fragments-00 

So I do recommend ATR and DNS message fragments should be both considered  in a tool box for large DNS response issues. 

Davey  

发件人: DNSOP [mailto:[email-masked]] 代表 william manning
发送时间: 2017年9月21日 1:30
收件人: Davey Song
抄送: dnsop
主题: Re: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt

/Wm

Hi folks, 

I just submit a draft dealing with issue of large DNS response especially in IPv6. Commnets are welcome. 

If chairs think it is in the scope of dnsop wg and encourage us to discuss it in this mailing list, I can submit it as a draft listed in dnsop wg.

Davey

---------- Forwarded message ----------
From: <[email-masked]>
Date: 11 September 2017 at 10:13
Subject: I-D Action: draft-song-atr-large-resp-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : ATR: Additional Truncated Response for Large DNS Response
        Author          : Linjian Song
        Filename        : draft-song-atr-large-resp-00.txt
        Pages           : 8
        Date            : 2017-09-10

Abstract:

https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Sep 2017 21:50:24 -0700

Davey Song(宋林健) wrote:
> Thank you.
>
> The large DNS response in IPv6 is a real problem. ATR is one option
> to adopted in authoritative  server alone. If someone or party have
> more influence on both resolver and authoritative side (cloud and app
> provider who can choose their own DNS resolution path),  Mukund’s
> proposal to fragment the DNS message is a good
> solution.https://tools.ietf.org/html/draft-muks-dns-message-fragments-00

both ideas are wrong. what we have to do is arrange to fragment, using 
the ipv6 extension header, all ipv6 udp, for a period of not less than 
five years. noone who blocks ipv6 extension headers should be able to 
get reliable ipv6 udp services. we have to make this problem felt where 
it is made. we must NOT work around it to insulate the makers of the 
problem from the costs of their actions.

> So I do recommend ATR and DNS message fragments should be both
> considered  in a tool box for large DNS response issues.

can a freebsd kernel hacker please contact me? i need some patches, but 
i'm traveling extensively, and i can't do the investigation and software 
engineering myself.

-- 
P Vixie

---

From: Davey Song(宋林健) <[email-masked]>
Date: Thu, 21 Sep 2017 15:08:32 +0800

Hi Paul, 

I know you suggest expose the problem and let the trouble maker feeling the pain themselves. But return to the specific issue, from APNIC's measurement the ASes in the path are dropping the fragments, rather than end ASes. From these ASes' view , it's your pain not theirs. 

In another word, we are facing the fragmented and uncooperative Internet. What should we do ? It is very hard to coordinate all parts and networks. DNS is a field with lots of tussle.

Davey

> -----邮件原件-----
> 发件人: DNSOP [mailto:[email-masked]] 代表 Paul Vixie
> 发送时间: 2017年9月21日 12:50
> 收件人: "Davey Song(宋林健)"
> 抄送: 'Davey Song'; 'dnsop'; 'william manning'
> 主题: Re: [DNSOP] 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt
> 
> 
> 
> Davey Song(宋林健) wrote:
> > Thank you.
> >
> > The large DNS response in IPv6 is a real problem. ATR is one option to
> > adopted in authoritative  server alone. If someone or party have more
> > influence on both resolver and authoritative side (cloud and app
> both ideas are wrong. what we have to do is arrange to fragment, using the
> ipv6 extension header, all ipv6 udp, for a period of not less than five years.
> noone who blocks ipv6 extension headers should be able to get reliable ipv6 udp
> services. we have to make this problem felt where it is made. we must NOT
> work around it to insulate the makers of the problem from the costs of their
> actions.
> 
> can a freebsd kernel hacker please contact me? i need some patches, but i'm
> traveling extensively, and i can't do the investigation and software engineering
> myself.
> 
> --
> P Vixie
>

---

From: Davey Song(宋林健) <[email-masked]>
Date: Thu, 21 Sep 2017 15:08:32 +0800

Hi Paul, 

Davey

---

From: Jim Reid <[email-masked]>
Date: Thu, 21 Sep 2017 08:22:17 +0100

> On 21 Sep 2017, at 08:08, Davey Song(宋林健) <[email-masked]> wrote:
> 
> In another word, we are facing the fragmented and uncooperative Internet. What should we do ?

Switch it off? Hand it over to ITU control? :-)

The Internet was designed from the outset to work around breakage. Packet fragmentation issues will always be with us unfortunately. The networks which have these problems will fix them: Darwinism will take care of that eventually. Until then everyone else just has to work around them or ignore their brokenness. 'coz that's how it works.

We (for some definition of we) might come up with some tools to help identify the problem or do some outreach and education to help mend these broken networks. However I am sceptical those sort of things will be successful. After all we still have nets, servers and middleboxes that can't/won't handle EDNS correctly or assume that DNS packets only ever go over UDP and are always < 512 bytes.

---

From: Davey Song(宋林健) <[email-masked]>
Date: Thu, 21 Sep 2017 17:26:02 +0800

OK. I finally understand the context of the word " Darwinism " in many IETF discussion and slides. Haha~

Davey
> -----邮件原件-----
> 发件人: Jim Reid [mailto:[email-masked]]
> 发送时间: 2017年9月21日 15:22
> 收件人: "Davey Song(宋林健)"
> 抄送: Paul Vixie; dnsop WG
> 主题: a fragmented and uncooperative Internet
> 
> 
> The Internet was designed from the outset to work around breakage. Packet
> fragmentation issues will always be with us unfortunately. The networks which
> have these problems will fix them: Darwinism will take care of that eventually.
> Until then everyone else just has to work around them or ignore their
> brokenness. 'coz that's how it works.
> 
> We (for some definition of we) might come up with some tools to help identify
> the problem or do some outreach and education to help mend these broken
> networks. However I am sceptical those sort of things will be successful. After
> all we still have nets, servers and middleboxes that can't/won't handle EDNS
> correctly or assume that DNS packets only ever go over UDP and are always <
> 512 bytes.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Sep 2017 08:52:42 -0400

Hi,

On Wed, Sep 20, 2017 at 09:50:24PM -0700, Paul Vixie wrote:
> 
>  what we have to do is arrange to fragment, using the
> ipv6 extension header, all ipv6 udp, for a period of not less than five
> years. noone who blocks ipv6 extension headers should be able to get
> reliable ipv6 udp services. we have to make this problem felt where it is
> made. we must NOT work around it to insulate the makers of the problem from
> the costs of their actions.

I think that the above suggestion needs to define carefully who "we"
is in each sentence.  Because I am very far from convinced that the
"we" in each case is the same people, and also very far from convinced
that we are going to be able to "make" this happen, given our lack of
protocol police.  Operators have one incentive, which is to make their
customers stop calling; if our plan is to make IPv6 even less reliable
than it has been historically, I think the operators are going to point
us to the nearest short pier and tell us to take a long walk.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Sep 2017 19:31:29 -0700

Davey Song(宋林健) wrote:
> Hi Paul,
>
> I know you suggest expose the problem and let the trouble maker
> feeling the pain themselves. But return to the specific issue, from
> APNIC's measurement the ASes in the path are dropping the fragments,
> rather than end ASes. From these ASes' view , it's your pain not
> theirs.

it's a question of first mover advantage. EDNS will never be fully 
deployed, because of the middleboxes built before 1999 who "know" what a 
UDP/53 datagram has to look like, and which disallow ADCOUNT>0 && QR=0.

we can, if we wish, continue to standardize one protocol, watch as the 
world deploys a different one, and still pretent that our effort was 
worthwhile. however, this would fit the technical definition of 
"insanity", and i urge that we avoid this course of action.

> In another word, we are facing the fragmented and uncooperative
> Internet. What should we do ? It is very hard to coordinate all parts
> and networks. DNS is a field with lots of tussle.

we need a kernel option for various open source operating systems which 
causes all UDP to be fragmented at 512 octets of payload. for ipv4, so 
that we can hard-smash every middlebox which still prevents EDNS from 
being deployed, and for ipv6 also, so that we can hard-smash any middle 
or edge network who won't carry ipv6 extension headers.

and we need to turn this on everywhere. root, gtld, cctld, recursives, 
authoriatives, 8.8.8.8, opendns... Everywhere. with a press release to 
pre-announce the flag day.

if we're not going to stand up for the standards we write, then we 
should admit that nothing except tcp/80 will work, and avoid all else.

-- 
P Vixie

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Sep 2017 13:13:58 +1000

In message <[email-masked]>, Paul Vixie writes:
> Davey Song() wrote:

The ones built after 1999 that assume EDNS will always have a version
field of zero, or that there won't be any EDNS options, or that
there won't be any EDNS flags bits, other than DO, are the biggest
problem.

> should admit that nothing except tcp/80 will work, and avoid all else.

Just padding UDP responses to EDNS buffer size should be enough to
force fragmentation.  If you advertise a 4096 buffer you should be
able to accept such a response.

We also need to bump the EDNS version number.  Going to EDNS(1)
will hit the firewalls that think EDNS(0) is the only EDNS version
they will ever see.

BIND 9.11 is already adding a DNS COOKIE option to every request.
That is causing some firewalls to be fixed as well as some nameservers.
We haven't added additional workaround code for this.

Mark

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Sep 2017 20:41:12 -0700

Mark Andrews wrote:
...
> able to accept such a response.

i don't want to waste the octets. a lot of links are still mobile. 
forcing source fragmentation for payloads longer than 512 will do.

> will hit the firewalls that think EDNS(0) is the only EDNS version

that would drag in version negotiation -- a lot of responders would say 
BADVERS which would lead, best case, to another round trip. but since 
the version negotiation code paths aren't tested, it may be worse.

> We haven't added additional workaround code for this.

nice. thanks for that.

-- 
P Vixie

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Sep 2017 14:24:52 +1000

> forcing source fragmentation for payloads longer than 512 will do.

Setsockopt IPV6_USE_MIN_MTU=1 for IPv6.
 
> the version negotiation code paths aren't tested, it may be worse.

Version negotiation occuring will self correct.  A extra round trip
isn't too expensive.  We get enough FORMERR/BADVERS to EDNS(0) +
DNS COOKIE queries to know that it isn't a practical issue.

I've tested enough version negotiation paths.  See https://ednscomp.isc.org/
The entries with "badversion" show a failed EDNS version negotiation.
The entire Alexa top 1M is scanned once a month.

	EDNS(0) + rcode != BADVERS -> badversion
	BADVERS + response version >= request version -> badversion

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Sep 2017 15:04:41 +1000

> The entire Alexa top 1M is scanned once a month.

I've added a link to the raw data for those that want to investigate further.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 22 Sep 2017 09:58:42 -0400

On Thu, Sep 21, 2017 at 07:31:29PM -0700, Paul Vixie wrote:
> we can, if we wish, continue to standardize one protocol, watch as the world
> deploys a different one, and still pretent that our effort was worthwhile.
> however, this would fit the technical definition of "insanity", and i urge
> that we avoid this course of action.

[…]

> causes all UDP to be fragmented at 512 octets of payload.

If working on a protocol that merely depends on certain middleboxes
eventually die is "insanity", what do we call it when people work on a
protocol that depends on UDP fragments working everywhere?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: P Vix <[email-masked]>
Date: Fri, 22 Sep 2017 15:43:43 +0000

>protocol that depends on UDP fragments working everywhere?

"Untried."
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: william manning <[email-masked]>
Date: Sat, 23 Sep 2017 05:29:20 -0700

there is some evidence to suggest that two factors will drive increasingly
large responses.  first is signing with multiple algorithms and second is
increases in key sizes.  in a worst case model, we have to shift to
the McEliece
cryptosystem, post quantum crypto. for a standard selection of parameters,
the public key is 512 kilobits long.  for quantum computing, key sizes must
be increased by a factor of four due to improvements in information set
decoding.  Attacking and defending the *McEliece cryptosystem*
<https://www.google.com/url?url=http://scholar.google.com/scholar_url%3Furl%3Dftp://nozdr.ru/biblio/kolxo3/Cs/CsLn/Post-Quantum%252520Cryptography,%2525202%252520conf.,%252520PQCrypto%2525202008(LNCS5299,%252520Springer,%2525202008)(ISBN%2525209783540884026)(239s).pdf%2523page%253D40%26hl%3Den%26sa%3DX%26scisig%3DAAGBfm0XEERxI9tL9IfgPGaNOklLIG0r1Q%26nossl%3D1%26oi%3Dscholarr&rct=j&q=&esrc=s&sa=X&ved=0ahUKEwiD6ue0pbvWAhVY-GMKHeFKBUIQgAMIJygAMAA&usg=AFQjCNHV1StJs0Pom6FVNA77UEgVzinRbw>
 - ‎Bernstein   ....   so, yes, bigger responses should be planned for.
Anyone for DNS over BitTorrent?  :)

/Wm

On Wed, Sep 20, 2017 at 8:22 PM, Davey Song(宋林健) <[email-masked]> wrote:

> So I do recommend ATR and DNS message fragments should be both considered
>  in a tool box for large DNS response issues.
>
>
>
> Davey
>
>
>
> *发件人:* DNSOP [mailto:[email-masked]] *代表 *william manning
> *发送时间:* 2017年9月21日 1:30
> *收件人:* Davey Song
> *抄送:* dnsop
> *主题:* Re: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt
>
>
>

---

From: william manning <[email-masked]>
Date: Sat, 23 Sep 2017 05:34:54 -0700

You wrote; "we can, if we wish, continue to standardize one protocol, watch
as the world deploys a different one, and still pretent that our effort was
worthwhile. however, this would fit the technical definition of "insanity",
and i urge that we avoid this course of action."

The IETF has been doing this for years, why stop now?   Pragmatically, this
is why Randy Bush refers to the IETF as the IVTF.

On Thu, Sep 21, 2017 at 7:31 PM, Paul Vixie <[email-masked]> wrote:

> worthwhile. however, this would fit the technical definition of "insanity",
> and i urge that we avoid this course of action.
>
> causes all UDP to be fragmented at 512 octets of payload. for ipv4, so that
> we can hard-smash every middlebox which still prevents EDNS from being
> deployed, and for ipv6 also, so that we can hard-smash any middle or edge
> network who won't carry ipv6 extension headers.
>
> if we're not going to stand up for the standards we write, then we should
> admit that nothing except tcp/80 will work, and avoid all else.
>
> --
> P Vixie
>
>

---

From: Florian Weimer <[email-masked]>
Date: Mon, 25 Sep 2017 14:01:52 +0200

> problem from the costs of their actions.

I disagree with this approach.  Just avoid fragmentation altogether.  We 
know that it's harmful and can be used to bypass existing DNS hardening 
features.  Within five or ten years, packet rates have increased so much 
that the additional protection afforded by the 32-bit reassembly ID in 
IPv6 isn't sufficient anymore, either.

IP fragmentation is dead.  Use something else.

Thanks,
Florian