In message <20170922042453.08ea187a1...@rock.dv.isc.org>, Mark Andrews writes:
> 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.
I've added a li
In message <59c48658.9000...@redbarn.org>, Paul Vixie writes:
> Mark Andrews wrote:
> ...
> > 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.
>
> i don't want to waste the
Mark Andrews wrote:
...
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.
i don't want to waste the octets. a lot of links are still mobile.
forcing source fragmentation for pa
In message <59c47601.5030...@redbarn.org>, Paul Vixie writes:
> 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
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
Hello,
On 21 Sep 2017, at 18:01, Evan Hunt wrote:
On Thu, Sep 21, 2017 at 02:20:15PM +0200, Peter van Dijk wrote:
thank you for this, I like it a lot. One nit below.
Me too, with another nit...
This creates a kind of confusion, however, because the answer
to a
query that resul
On Thu, Sep 21, 2017 at 02:20:15PM +0200, Peter van Dijk wrote:
> thank you for this, I like it a lot. One nit below.
Me too, with another nit...
> > This creates a kind of confusion, however, because the answer to a
> > query that results in CNAME processing contains in the echoed
>
Jim Reid wrote:
>
> Maybe the definition of QNAME (effective) needs to be extended to
> include the result of NAPTR record processing? Says he running away
> quickly...
As I understand it, NAPTR processing happens in applications outside the
DNS so the result is a QNAME (original) from the DNS po
> On 21 Sep 2017, at 14:12, Shumon Huque wrote:
>
> On Wed, Sep 20, 2017 at 11:45 PM, Andrew Sullivan
> wrote:
>
> To address this potential confusion, it is helpful to distinguish
> between two meanings:
>
> QNAME (original) The name actually sent in the Question
>
On Wed, Sep 20, 2017 at 11:45 PM, Andrew Sullivan
wrote:
>
> To address this potential confusion, it is helpful to distinguish
> between two meanings:
>
> QNAME (original) The name actually sent in the Question
> Section in the orignal query, which is always echoed in
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.
Hello Andrew,
thank you for this, I like it a lot. One nit below.
On 21 Sep 2017, at 5:45, Andrew Sullivan wrote:
> [RFC2308], however, has an alternate definition that puts the
> QNAME in the answer (or series of answers) instead of the query.
> It defines QNAME as: "...the na
OK. I finally understand the context of the word " Darwinism " in many IETF
discussion and slides. Haha~
Davey
> -邮件原件-
> 发件人: Jim Reid [mailto:j...@rfc1035.com]
> 发送时间: 2017年9月21日 15:22
> 收件人: "Davey Song(宋林健)"
> 抄送: Paul Vixie; dnsop WG
> 主题: a fragmented and uncooperative Internet
>
>
> On 21 Sep 2017, at 08:08, Davey Song(宋林健) 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 issue
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 anothe
15 matches
Mail list logo
