Just a point of clarification before the list moderator shuts down
this off-topic thread..
Ed's unstated assumption is that the condition being considered is
communication between two hosts that are both dual-stack. It is not
that he fails to understand that hosts that are now IPv4-only sh
That was my question. Matt's answer was that he did not remember that
detail of the design. Not remembering the detail that happened to be
omitted from the slide is not really the same as not in the design. I
am sure Matt and Joe know that signing the root means nothing without
the DS re
Thanks for explaining that.
Now, what about this other draft that seems to call for recursive
resolvers to know about address translation?
http://www.ietf.org/id/draft-vogt-durand-virtual-ip6-connectivity-01.txt
John
On 2009Jul21, at 2:32 PM, Andrew Sullivan wrote:
On Thu, Jul 09, 2009 at
Along with these good suggestions, the next draft should include a
brief description of why the desired behavior (as seen by the user) is
better performed through DNS tricks than through HTTP tricks.
John
On 2009Jul17, at 12:04 PM, Paul Hoffman wrote:
At 8:16 AM -0400 7/16/09, Livingood, J
Locus of control? Or that pesky old trust anchor?
Separable issues: where the validation computations are done, and
setting (and updating) the trust anchor. For computation, the
advantage of caching after validation in the (shared) recursive
resolver probably does not keep up with the per
RFC 2845 - Secret Key Transaction Authentication for DNS (TSIG)
This protocol allows for transaction level authentication using shared
secrets and one way hashing. It can be used to authenticate dynamic
updates as coming from an approved client, or to authenticate
responses as coming from a
Today's Behave agenda includes DNS.
Behave AGENDA
SESSION TWO
THURSDAY, 09:00-11:30
...
9:55 NAT64 (Marcelo
Bagnulo, 25)
draft-bagnulo-behave-nat64
10:20 DNS64 (Marcelo
Bagnulo, 20)
draft
As a prelude to my comments, I should say that I appreciate your
contribution, and do not intend to delay it. I think the reference
to RFC 2505 might fit properly in the history section. My reason for
advocating inclusion is like my reason for supporting the history
section in general: co
I think this background about the origin of "security" through
reverse lookup is helpful. Certainly not hurtful, which is what my
old rant about its use on UUnet's FTP server might be.
John
On May 31, 2007, at 5:24 PM, Andrew Sullivan wrote:
Dear colleagues,
We received a suggestion that
