On 2007-06-19 00:29, Azinger, Marla wrote:
Michael- I dont believe that was the intent and there might be a little
misinterpretation here due to how it was written. The document says:
The designated allocation authority is required to document how they
will meet the requirements
On 2007-06-19 22:15, Jeroen Massar wrote:
Manfredi, Albert E wrote:
Jeroen, what about this quote from the draft:
Sorry I mutilated your name again!
Don't worry about that, that happens everywhere (even I typo it) ;)
4.1 DNS Issues
and PTR records for centrally assigned local
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
On 2007-06-20 19:22, Scott Leibrand wrote:
Leo Vegoda wrote:
On 20 Jun 2007, at 12:36am, Scott Leibrand wrote:
[...]
Is this not already possible with a /48 PI assignment from ARIN?
Yes, but only if you qualify for an IPv4 assignment or allocation
from ARIN under the IPv4 policy currently
On 2007-06-21 04:03, Perry Lorier wrote:
james woodyatt wrote:
On 20 Jun 2007, at 15:10, Mark Smith wrote:
On Wed, 20 Jun 2007 11:16:15 -0700 james woodyatt [EMAIL PROTECTED] wrote:
I'd be more sympathetic to arguments like this if we RFC 4864 didn't
insist on recommending the deployment of
I'd be more sympathetic to arguments like this if we RFC
4864 didn't
insist on recommending the deployment of stateful packet filters in
IPv6 that break most of the things NAT breaks in IPv4.
It seems to me that you're
making the assumption that the only scenario IPv6 will be
Firewalls don't get upgraded to support SCTP and DCCP because
applications are all limping along with TCP and UDP. Egg:
meet chicken.
Sounds like a good area for standardization so that this state of
affairs is not carried forward into IPv6. And especially, if there is a
standard way for
This is the place for me to say that I believe the draft is
wrong in delegating this as an RIR policy matter. Like
existing ULAs, ULA-C should be treated as *technical* address
space, and we should specify that assignments will be made
and recorded by a single instance of a robot,
I see Thomas' argument for tolerating occasional use of entries in the
global DNS for ULAs - but it seems that it leads to too many complications
to be recommended. Since I'm sure the IETF isn't ready yet to endorse the
reality of split DNS deployment, wouldn't it be best to say that
I see Thomas' argument for tolerating occasional use of entries in the
global DNS for ULAs - but it seems that it leads to too many complications
to be recommended. Since I'm sure the IETF isn't ready yet to endorse the
reality of split DNS deployment, wouldn't it be best to say that
Mark Andrews [EMAIL PROTECTED] writes:
I see Thomas' argument for tolerating occasional use of entries in the
global DNS for ULAs - but it seems that it leads to too many complications
to be recommended. Since I'm sure the IETF isn't ready yet to endorse the
reality of split DNS
Le jeudi 21 juin 2007, Hemant Singh (shemant) a écrit :
Please see section 5 of our I-D for a proposed change to 2462bis-08 -
we hear this I-D is
in Editor's queue and any changes to it must be given ASAP.
Could you please use US-ASCII rather than UTF-16 for you I-D, as is
customary here?
Will do, thanks for this tip. I will send out another copy soon.
Hemant
-Original Message-
From: Rémi Denis-Courmont [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 12:36 PM
To: Hemant Singh (shemant)
Cc: ipv6@ietf.org
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00
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
On 20 Jun 2007, at 7:22pm, Scott Leibrand wrote:
[...]
So am I right in reading your answer as saying that the advantage
of ULA-C is that it solves the same problem that ARIN's IPv6 PI
policy solves but better. In effect, developing ULA-C helps side-
step ARIN's policy development process?
I concur wholeheartedly on all points. If one wants a universally
visable address use PI . With IPv6 if an organization cannot or refuses
to get their own PI space they can get space from their provider. When
they choose to change providers they are not renumbering, they are just
re-prefixing..
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
Leo Vegoda wrote:
On 20 Jun 2007, at 7:22pm, Scott Leibrand wrote:
So am I right in reading your answer as saying that the advantage of
ULA-C is that it solves the same problem that ARIN's IPv6 PI policy
solves but better. In effect, developing ULA-C helps side-step
ARIN's policy development
On 21 Jun 2007, at 10:06pm, Scott Leibrand wrote:
[...]
If ULA-C is not available, I believe many of those networks will
instead push for PI space. Once they get it, the path of least
resistance is announcing it globally, so most recipients of PI
space will do so, increasing pressure on
Maybe I am missing the point, but there seems to be
an implication that ULA-C necessarily implies IPv6
NAT; am I misinterpreting? If not, then I don't quite
understand why this implication is being drawn. Can
someone please explain?
Thanks - Fred
[EMAIL PROTECTED]
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
On Jun 21, 2007, at 15:26, Templin, Fred L wrote:
Maybe I am missing the point, but there seems to be an implication
that ULA-C necessarily implies IPv6 NAT; am I misinterpreting? If
not, then I don't quite understand why this implication is being
drawn. Can someone please explain?
I'm
-Original Message-
From: Scott Leibrand [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 5:13 PM
To: IETF IPv6 Mailing List
Subject: Re: draft-ietf-ipv6-ula-central-02.txt
james woodyatt wrote:
On Jun 21, 2007, at 15:26, Templin, Fred L wrote:
Maybe I am missing
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
On Jun 21, 2007, at 17:22, Templin, Fred L wrote
From: Scott Leibrand [mailto:[EMAIL PROTECTED]
That assertion has been made, but I don't think we can treat it as
anything more than a preference by non-technical business people.
[...] Some say: probability of collision must be zero, and
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
At Thu, 21 Jun 2007 12:31:58 -0400,
Hemant Singh (shemant) [EMAIL PROTECTED] wrote:
Please see section 5 of our I-D for a proposed change to 2462bis-08 - we
hear this I-D is
in Editor's queue and any changes to it must be given ASAP.
(with the document editor hat of 2462bis on)
From a quick
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
29 matches
Mail list logo
