From an Application (above TCP) perspective, A, definitely A. Itojun
summarizes well the issues. Mandating a host to know topology is just a
really bad thing. Really really bad.
paf
On tisdag, aug 5, 2003, at 03:09 Europe/Stockholm, Jun-ichiro itojun
Hagino wrote:
I would like to hear from
Bob Hinden writes:
> If this means globally routable provider independent addresses. Then it
> is, of course, correct that this would solve many of the problems
> too. Unfortunately, there is a big problem why this isn't a practical
> choice we can make now. We don't have, IMHO, any idea
Bob Hinden wrote:
[no hats on]
Then, we have a 'requirement' document that pretend to explain why we
need
'local' addresses. If you read it carefully, and as acknowledged by
one of its main
author in Vienna, almost all of those requirements (if not all) would
be fulfilled
by provider indepen
My primary concern is and always has been support for sites that
"bump into one another" from time to time, which can happen as result
of site mobility and/or temporal links between sites (e.g., VPNs, leased
lines, range-restricted wireless links, etc.) Also to support sites that are
intermittently
Tony Hain wrote:
There are some historic 'lessons learned' included here, but the real issue
is meeting the expectations of the network managers who are currently using
IPv4 logic. That is not to say we don't want them to change, but we can't
assume they will even be willing to consider something t
Michel Py wrote:
> > Todd T. Fries wrote:
> > What requirement of site-local does provider
> > independent addressing not provide?
>
> We do not have PI addresses for IPv6, to begin with. And the reason we
> don't is that as soon as you begin to think about them I can already
> hear screams about
Eliot Lear wrote:
> Hello,
>
> I've read over this draft, and I find it very confusing. The
> title of
> the draft is "Limited Range Addressing Requirements".
> However, as one
> goes through the document, there is both justification and
> requirements.
> What time is spent on the justif
Dan,
It occurs to me that if we are going to start actually counting again
(picking the option with the most votes) the options offered will tend
to skew the result towards A by splitting the site-local support between
B & C. Therefore I wish to cast my vote against A more than for C...
I am plan
Alain Durand wrote:
> ...
> IMHO, what need to happen is the following:
>
> -1. Make an in-depth study of the consequences of introducing
> addresses with different ranges.
This is not an introduction, they happened long ago ...
>
> -2. Realize that if the issue at stake here has more to
[no hats on]
Then, we have a 'requirement' document that pretend to explain why we need
'local' addresses. If you read it carefully, and as acknowledged by one of
its main
author in Vienna, almost all of those requirements (if not all) would be
fulfilled
by provider independent addresses. Actua
Hello,
I've read over this draft, and I find it very confusing. The title of
the draft is "Limited Range Addressing Requirements". However, as one
goes through the document, there is both justification and requirements.
What time is spent on the justification for "limited range" addressing
I think there is a small but important, difference here between what PI and
limited-range can provide.
1) PI needs some kind of registration process.
2) Limited-range can be an automatic process.
It seems to me that 2) make sense in small networks, like unmanaged networks, where
you will not as
> Todd T. Fries wrote:
> What requirement of site-local does provider
> independent addressing not provide?
We do not have PI addresses for IPv6, to begin with. And the reason we
don't is that as soon as you begin to think about them I can already
hear screams about having to carry an individual /
Jordi,
> Jordi wrote:
> I see your point, but my feeling is that we can only go to
> the last step (of the IETF process) IF it make sense (running
> code, and then it means no-brainer), that means that B is
> fine, but for the same reason, I can live with C (in theory,
> B and C are then the same
I'd like to third this motion.
Provider independent addressing is the number one gripe of a few people I know.
As things currently read, you're either an ISP, an infrastructure site, or
you do not get to multihome. Tell that to Dow Jones. They can rely on one
upstream isp, or get multiple alloc
> Dan Lanciani wrote:
> It occurs to me that if we are going to start actually
> counting again (picking the option with the most votes)
> the options offered will tend to skew the result towards
> A by splitting the site-local support between B & C.
> Therefore I wish to cast my vote against A mor
(Following up to my own message...)
|I vote for C. Given the disagreement on the "legitimate" uses of site local
|addresses (and scoped addressing in general) it will be difficult to be sure
|that a replacement actually solves all the problems that everyone concerned
|expected site-locals to solv
FWIW, I wasn't there but I agree with Alain. I've
never seen any compelling evidence that scope qua
scope is what people actually need. And scope
brings any number of architectural questions to
the fore. I'd be much, much more comfortable
having an up/down pronouncement on whether PI
addressing is
Bob Hinden wrote:
[IPv6 working group chair hat on]
I think the working group has been making good progress on replacing
site-local addresses and wanted to get feed back from the working
group on how we should move forward. This is not intended to directly
relate to the ongoing appeal of th
Hi Michel,
I see your point, but my feeling is that we can only go to the last step (of the IETF
process) IF it make sense (running code, and
then it means no-brainer), that means that B is fine, but for the same reason, I can
live with C (in theory, B and C are then the
same solution) ;-).
Reg
|C) Deprecate Site-Local addresses after an alternative is defined,
|standardized, and in operational practice. This would mean not advancing a
|deprecation document until there was operational evidence that the
|alternative was working and shown to be an improvement over Site-Local
|addresses
Bob,
> Bob Hinden wrote:
> Please respond to the list with your preference
I would prefer C. "Rough consensus and running code". Possibly I could
live with B, but it greatly depends on how difficult the new solution is
to implement. If everyone agrees that implementing the new solution is a
no-br
My understanding of the WG discussion is that deprecation of site-local
addresses was discussed and consensus was reached independent of the
availability of any alternative solution. Therefore, based on what I
understand to be WG consensus, A is the appropriate way to proceed.
That's not to sa
Given the requirements from edge network managers I have talked to, I would
prefer C, but could live with B.
Tony
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bob Hinden
> Sent: Monday, August 04, 2003 11:07 AM
> To: [EMAIL PROTECTED]
> Cc: [EM
kre wrote:
>
> | All documents produced as part of this course of action will
> | be subject to discussion by the WG, and they will go through
> | WG last call, etc. In keeping with normal IETF processes,
> | these documents won't be sent to the IESG unless they
> | represent the co
Hi Bob,
I think option B is a balanced alternative, unless someone can open my eyes about any
cons on this one.
Regards,
Jordi
- Original Message -
From: "Bob Hinden" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, August 04, 2003 8:06 PM
Subject: Movi
[IPv6 working group chair hat on]
I think the working group has been making good progress on replacing
site-local addresses and wanted to get feed back from the working group on
how we should move forward. This is not intended to directly relate to the
ongoing appeal of the working groups deci
Todd,
> Todd T. Fries wrote:
> Either you have link-local addresses, or you have
> global routable addresses.
>From a transit provider point of view this is true, but not for the
enterprise. There are lots of large networks that require private
addresses and use RFC1918 today. Examples that have
This is the combined Tony Hain and Fred Templin requirements
document. Many thinks to Tony and Fred for getting this out quickly.
Bob
To: IETF-Announce: ;
From: [EMAIL PROTECTED]
Reply-to: [EMAIL PROTECTED]
Subject: I-D ACTION:draft-hain-templin-ipv6-limitedrange-00.txt
Date: Mon, 04 Aug 2003
Hi Todd,
I feel that we will have NAT-like situation in both cases (with/without site-local).
If we don't provide a "site-local" kind of address space (I prefer to say
limited-range), the people will use any global prefix,
trying to filter it, and sometimes creating global routing problems/confl
While I do not pretend to be the most versed in all of the IPv6 related RFC's,
I am questioning what the goals of site-local or a similar replacement
would be.
Either you have link-local addresses, or you have global routable addresses.
Any attempt at providing something that is site local sugges
Hi Tony, Fred,
In principle, I like the document, but I will much prefer that "private addresses" is
not used, or at least is more clarified. I
just try to avoid the relation of this "limited range" to the possibility of a
NAT-like mechanism ...
Regards,
Jordi
- Original Message -
Fro
Brian,
> Brian E Carpenter wrote:
> Personally, I'd advise customers who believe they need local
> addresses to continue using FEC0 until the addressing
> architecture is revised and products catch up.
Oops I goofed. s/incertitude/uncertainty
Customers don't like uncertainty when designing netwo
Brian,
> Brian E Carpenter wrote:
> Personally, I'd advise customers who believe they need local
> addresses to continue using FEC0 until the addressing
> architecture is revised and products catch up.
Customers don't like incertitude when designing networks and will delay
IPv6 deployment until t
Michel Py wrote:
...
> An imperfect solution is better than no solution
Not if it's more harmful than the absence of a solution, which may
well be the case in this instance (although that is a matter of
judgement).
> and until we find a
> better mouse trap it is harmful to deprecate the running
Scott Bradner wrote:
>
> fwiw - I fully agree with kre
> (that has happened before in case anyone wondered)
fwiw, I don't (and I have both agreed and disagreed with kre
and sob in the past).
I really think this is a distraction. Objectively, the WG is
getting on with the three things that need t
Date:Sun, 03 Aug 2003 12:33:08 -0400
From:Margaret Wasserman <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
I am not planning on debating these issues here, again, so just this
one message...
| An initial draft agenda, which did list the local addressing
| to
37 matches
Mail list logo
