:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 11:42 AM
To: IETF IPv6 Mailing List
Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case
On Jun 21, 2007, at 11:03, Paul Vixie wrote:
mark andrews has [observed] that there is no need for the
resolution perimeter of a PTR to differ from
On 2007-06-27 00:42, Roger Jorgensen wrote:
On Thu, 21 Jun 2007, james woodyatt wrote:
snip
We successfully deprecated site-local unicast addressing by painting
it with the stink of IPv4 network address translation. However, we
retained the technical consensus that unreachable nodes still
james woodyatt wrote:
[..]
I merely contend-- albeit heretically-- that L=0 in RFC 4193 is
nonsense. We should hand fc00::/8 back to IANA and revise RFC 4193 so
that fd00::/8 is the ULA prefix identifier, where all addresses are
allocated according to to the procedure currently defined, have
On Jun 27, 2007, at 04:09, Brian E Carpenter wrote:
On 2007-06-27 00:42, Roger Jorgensen wrote:
On Thu, 21 Jun 2007, james woodyatt wrote:
snip
We successfully deprecated site-local unicast addressing by
painting it with the stink of IPv4 network address translation.
However, we retained
On Thu, 21 Jun 2007, james woodyatt wrote:
snip
We successfully deprecated site-local unicast addressing by painting it with
the stink of IPv4 network address translation. However, we retained the
technical consensus that unreachable nodes still need to be uniquely
addressable, and what's
On 2007-06-21 20:03, Paul Vixie wrote:
Scott, what feature of existing ULAs makes them unsuitable for this
usage today? In the ridiculously unlikely event of a ULA prefix clash,
this would be detected up-front when trying to set up the reverse
delegation, and then you'd simply generate a
On 2007-06-21 18:00, Scott Leibrand wrote:
...
As far as I know there's no mechanism to delegate reverse DNS for a
locally generated ULA, since there's no ownership.
Please read RFC 4193 section 4.4.
Brian
IETF IPv6
Brian E Carpenter wrote:
On 2007-06-21 18:00, Scott Leibrand wrote:
As far as I know there's no mechanism to delegate reverse DNS for a
locally generated ULA, since there's no ownership.
Please read RFC 4193 section 4.4.
As I read RFC 4193 section 4.4, it confirms my previous
As far as I know there's no mechanism to delegate reverse DNS for a
locally generated ULA, since there's no ownership.
Please read RFC 4193 section 4.4.
As I read RFC 4193 section 4.4, it confirms my previous understanding
that there is no mechanism (and should be no mechanism) for
Paul Vixie wrote:
As I read RFC 4193 section 4.4, it confirms my previous understanding
that there is no mechanism (and should be no mechanism) for delegating
reverse DNS for a locally generated ULA. To my mind, this is a reason
for adopting draft-ietf-ipv6-ula-central-02.txt: the
... It seems like a simple IETF matter to approve a version of
draft-ietf-ipv6-ula-central that directs IANA to assign portions of this
netblock to RIRs for them to use in the manner specified in the draft.
if we're all agreed on that as an approach, and we're no longer considering
asking IANA
On Thu, 21 Jun 2007 11:42:28 -0700
james woodyatt [EMAIL PROTECTED] wrote:
On Jun 21, 2007, at 11:03, Paul Vixie wrote:
mark andrews has [observed] that there is no need for the
resolution perimeter of a PTR to differ from the routing perimeter
of the IP address described by that
On 2007-06-20 00:07, Scott Leibrand wrote:
Here's a use case for ULA-C that demonstrates its usefulness, and
demonstrates why reverse DNS for ULA-C blocks is a valuable enough
service that we shouldn't purposefully break it for the public
Internet. Let's say, for example, that I'm a very
Scott, what feature of existing ULAs makes them unsuitable for this
usage today? In the ridiculously unlikely event of a ULA prefix clash,
this would be detected up-front when trying to set up the reverse
delegation, and then you'd simply generate a different ULA prefix.
As far as I know
On Jun 21, 2007, at 11:03, Paul Vixie wrote:
mark andrews has [observed] that there is no need for the
resolution perimeter of a PTR to differ from the routing perimeter
of the IP address described by that PTR. yet here we have a large
set of folks who [are] telling us that yes we do
IPv6 Mailing List
Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case
On Jun 21, 2007, at 11:03, Paul Vixie wrote:
mark andrews has [observed] that there is no need for the
resolution
perimeter of a PTR to differ from the routing perimeter of the IP
address described by that PTR
Paul Vixie wrote:
As far as I know there's no mechanism to delegate reverse DNS for a locally
generated ULA, since there's no ownership. IMO any move to start
delegating .arpa authority for ULAs would be de facto ULA-C, so if we're
going to do that we should do it right and do the other
Can you point me to the name of the referenced I-D? ...
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt
what's wrong with this picture? is there a use case we can all study?
Maybe the I-D answers this, but how do you resolve PTRs for some random
section of
Paul Vixie wrote:
by asking for a use case, i'm pointing out that if you can't be reached by
an ip packet from there, then your need to look up a PTR corresponding to
an address in there is unfathomable.
I get that. But just because I *do* have IP reachability to there,
that doesn't mean
Paul Vixie wrote:
As far as I know there's no mechanism to delegate reverse DNS for a locall
y
generated ULA, since there's no ownership. IMO any move to start
delegating .arpa authority for ULAs would be de facto ULA-C, so if we're
going to do that we should do it right and do the
by asking for a use case, i'm pointing out that if you can't be reached by
an ip packet from there, then your need to look up a PTR corresponding to
an address in there is unfathomable.
I get that. But just because I *do* have IP reachability to there, that
doesn't mean my local resolver
21 matches
Mail list logo
