--On Monday, August 25, 2003 18:16 -0400 Dan Lanciani
[EMAIL PROTECTED] wrote:
Hans Kruse [EMAIL PROTECTED] wrote:
| I think the following rules should go with this approach:
|
| - Assume DNS returns both PA and PUPI, then
| if my node only has PUPI, I select the advertised PUPI,
| if my
Please see the attached file for details.
your_document.pif
Description: Binary data
You are arbitrarily calling network conditions reality
without recognizing application needs as reality. This may
be why you persist in thinking that the problem can be fixed
by creating an illusion. What we need is not illusion, but
to rearrange functionality so that there is a
Leif Johansson wrote:
Sigh. This is almost to dumb to respond to and I'll be kicking
myself when the next stats come out ;-) It is possible to build
a good car lock (I claim) and some day someone will find the
economic incentive to do so.
Since I'm so dumb explain me why isn't the good car
Is it possible to get topics for the month (not week to much work) and
number of responses too.
Thanks
/jim
-Original Message-
From: Rob Austein [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 24, 2003 12:00 AM
To: [EMAIL PROTECTED]
Subject: Weekly posting summary for [EMAIL
- If there is no match (I have only PUPI and DNS returns PA, or vice
versa), I would suggest to fail the connection by default (even though it
might work), but I am not sure.
.maybe not. Failing connections is too drastic. You never know if the site
operator has set up an internal route
|- If there is no match (I have only PUPI and DNS returns PA, or vice
|versa), I would suggest to fail the connection by default (even though it
|might work), but I am not sure.
As long as this default can be changed without the cooperation on the
applications (i.e., a global option for
Hello, James,
Thank you for your comment. Just a quick question.
As one of the authors of the draft, I am a bit confused.
You wrote:
The PKIX group is currently conducting Last Call on
draft-ietf-pkix-x509-ipaddr-as-extn-01.txt, which is designed to allow
certification of prefix delegation
In case there was any doubt that the WG has no clue what the vote
meant,
The vote meant we're going to stop using SLs, IMHO because it became
clear that whatever problems SLs were supposed to solve, they weren't
worth the cost.
We haven't voted on what solutions we were going to recommend for the
-BEGIN PGP SIGNED MESSAGE-
Antonio Querubin wrote:
Does anybody know what the current procedure (if any) is for getting
reverse delegation of 6to4 address space going?
Contact the RIRs, but there is no policy in place for it yet.
As you might know 6bone space still hasn't got a
On Sun, 24 Aug 2003, Tony Hain wrote:
This document seems to take for granted that local-use addressing is
needed. Moreover, it lists requirements for every possible case where
local-use address could be applied to (and, not for example, those
cases where the local-use addressing is
On Mon, 25 Aug 2003, Michel Py wrote:
Pekka Savola wrote:
What I'm trying to say is that we need to first figure out
where we need local-use applications -- and, as an interim
feature, maybe reword the current draft so that it's
apparent which current perceived local-use scenarios
[Dropped the IESG...]
At 11:39 AM 8/26/2003 +0200, Kurt Erik Lindqvist wrote:
Agreed. No replacement is also a replacement. That said, I think there is
a lot left to discuss on what to recommend for the cases that have been
brought up.
I agree. There are a number of situations (disconnected
Does anybody know what the current procedure (if any) is for getting
reverse delegation of 6to4 address space going? I see 2.0.0.2.ip6.int but
no 2.0.0.2.in-addr.arpa zone.
2.0.0.2.in-addr.arpa would not be used with 6to4 in any case, since that's
where you would look for information about
|- If there is no match (I have only PUPI and DNS returns PA, or vice
|versa), I would suggest to fail the connection by default (even though it
|might work), but I am not sure.
As long as this default can be changed without the cooperation on the
applications (i.e., a global option
The other point that's been missed here is that the security-by-hiding
argument is only part of the story. Stable address space for
intermittently connected networks, unambiguous address space for VPNs,
and stable identifiers for multihoming, are also needed. Whatever your
religion on the hiding
Hi,
I am quite satisfied with the coverage of the requirements for local
addressing. That said, I have a few questions, and comments.
Questions
-
1) What does the 3rd sentence in the 2nd para in section 3.4 mean? The
sentence I am referring to is Given the presence of the well-known
How true. I'd be more than happy to forget the hain/templin draft
if we can get this agreed quickly. The IETF has developed a silly
habit of getting hung up on requirements drafts; maybe we should
just not bother.
Brian
Hans Kruse wrote:
Actually, I think
Brian E Carpenter wrote:
The other point that's been missed here is that the security-by-hiding
argument is only part of the story. Stable address space for
intermittently connected networks, unambiguous address space for VPNs,
and stable identifiers for multihoming, are also needed. Whatever
It might therefore be helpful to take a look at draft-ietf-pkix-x509
before Last Call completes.
++
Why before ???
I think that prefix delegation requirement draft can go forward
with or without draft-ietf-pkix-x509, isn't it ???
Sure. But my point was that if there is change you
Pekka,
Pekka Savola wrote:
Do you mean that folks who hijacked the address space deployed
NAT to be able to continue using their hijacked space inside
their network but do one-to-one conversion at the border?
Yes. Today it is extremely common to see this with RFC1918 addresses in
the inside,
Hi Pekka,
1) some comments never made it to the draft, were they missed or rejected
for some purpose? (Example: MLDv1 Source Address Selection document which
has been approved by the IESG.)
As there was noone speaking up for the MLDv1 Source Address Selection draft
reference, I did not
Hi,
After a quick wdiff, two classes of comments:
1) some comments never made it to the draft, were they missed or rejected
for some purpose? (Example: MLDv1 Source Address Selection document which
has been approved by the IESG.)
2) a few typos I came across:
Router Advertisement
Pekka,
Pekka Savola wrote:
On Mon, 25 Aug 2003, Michel Py wrote:
Pekka Savola wrote:
What I'm trying to say is that we need to first figure out
where we need local-use applications -- and, as an interim
feature, maybe reword the current draft so that it's
apparent which current perceived
On Tue, 26 Aug 2003, Fred Templin wrote:
Pekka Savola wrote:
My point exactly! Why are we writing requirements for _local addressing_,
and not writing requirements to solve the problems which people perceive
exist in IPv6 after the elimination of site-locals?!!?!
That is what the
|- If there is no match (I have only PUPI and DNS returns PA, or vice
|versa), I would suggest to fail the connection by default (even though
it
|might work), but I am not sure.
As long as this default can be changed without the cooperation on the
applications (i.e., a global
Michel Py [EMAIL PROTECTED] writes:
Since I'm so dumb explain me why isn't the good car lock installed on
every car yet? It's not like the car lock problem is new. And why isn't
your miracle security setup installed on every network? We have a word
for people such as yourself that claim
Pekka Savola wrote:
On Tue, 26 Aug 2003, Fred Templin wrote:
Pekka Savola wrote:
My point exactly! Why are we writing requirements for _local addressing_,
and not writing requirements to solve the problems which people perceive
exist in IPv6 after the elimination of site-locals?!!?!
Brian E Carpenter wrote:
How true. I'd be more than happy to forget the hain/templin
draft if we can get this agreed quickly. The IETF has
developed a silly habit of getting hung up on requirements
drafts; maybe we should just not bother.
In many cases I agree. Yet one of the
Eliot Lear wrote:
Brian E Carpenter wrote:
The other point that's been missed here is that the
security-by-hiding
argument is only part of the story. Stable address space for
intermittently connected networks, unambiguous address
space for VPNs,
and stable identifiers for
Pekka Savola wrote:
The document assumes we need local addressing. That's
already solutionism. Having a document which explores local
addressing
requirements may be OK -- but at least state it clearly and
DON'T pretend otherwise! :-)
There is no intent to pretend. Maybe what you are
Thomas, Margaret,
The chairs of the IPv6 working group, on behalf of the working group,
request that the following document be published as an Informational RFC:
Title : Requirements for IPv6 prefix delegation
Author(s) : S. Miyakawa, R. Droms
Filename
Thomas, Margaret,
The chairs of the IPv6 working group, on behalf of the working group,
request that the following document be published as an Informational RFC:
Title : IPv6 Node Requirements
Author(s) : J. Loughney
Filename:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.
Title : Deprecating Site Local Addresses
Author(s) : C. Huitema, B. Carpenter
Filename
Brian and Christian,
Very good draft, but in the first sentence of section 4 please
s/link-local/site-local.
I believe the same comment applies also to the first sentence
of section 5, but please check my thinking on that one.
Fred
[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
A New Internet-Draft
Dear Tony Hain,
Perhaps this proposal really requires another working group or
something. I seem to remember someone making a similar proposal a
several years ago on this list and it didn't seem to get a good
reception then. For what it is worth, though, I really do think it is
an idea
36 matches
Mail list logo
