Alain Durand wrote:
This recent thread is stressing the fact that what is really needed is
easy access
to stable address space.
Getting this address space from an ISP, a LIR or a RIR is just a minor
variation.
The point is that this can be solved by policy and does not require to
put
Pekka Savola wrote:
...
Sure, but there are also other ways to obtain addresses.
Really? Would you care naming one available today?
a) talk to your ISP (or one of its upstreams), which his hopefully a LIR,
or
b) talk to any LIR, and pay him e.g. 100$/mo. He'll gladly give you
If I get a
/48 from ISP A, and want to use it in private mode to set up VPNs
to business partners who have their public connectivity from ISPs A, B
and C, this /48 is going to cause various forms of head scratching
for the operations people at all those business partners, and if it
leaks,
On Mon, 8 Sep 2003, Brian E Carpenter wrote:
Pekka Savola wrote:
...
Sure, but there are also other ways to obtain addresses.
Really? Would you care naming one available today?
a) talk to your ISP (or one of its upstreams), which his hopefully a LIR,
or
b) talk to any
-BEGIN PGP SIGNED MESSAGE-
Michel Py wrote:
Pekka Savola wrote:
Sure, but there are also other ways to obtain addresses.
Michel Py wrote:
Really? Would you care naming one available today?
a) talk to your ISP (or one of its upstreams), which his
hopefully a LIR, or b)
-BEGIN PGP SIGNED MESSAGE-
Pekka Savola wrote:
ISP A, on the other hand, knows that the prefix is non-routed. If someone
asks, they can tell as much. Or even register it in RIR DB as an
unnumbered non-routed customer (if they don't want to reveal more
information on that) .. no
This recent thread is stressing the fact that what is really needed is
easy access
to stable address space.
Getting this address space from an ISP, a LIR or a RIR is just a minor
variation.
The point is that this can be solved by policy and does not require to
put anything in the architecture
Alain Durand wrote:
This recent thread is stressing the fact that what is really needed is
easy access to stable address space.
... without any contingency on the existence or lack thereof of a 'higher
level' address provider.
Getting this address space from an ISP, a LIR or a RIR is just a
Mark Smith wrote:
I do like the idea of autoconfiguration, but in larger networks,
it can start to work against you - your network can start doing
things behind your back that make it terrible to diagnose faults.
Indeed. Trouble is with all automated systems is that the engineer that
That is what the hain/templin draft is about! The title of the draft is:
Addressing Requirements for Local Communications within Sites
Is the title supposed to be a pun? I.e., do you mean to find solutions
to requirements for local communications .. or finding requirements for
On Wed, 27 Aug 2003 12:50:01 +1000
Andrew White [EMAIL PROTECTED] wrote:
I agree with Brian - the security issues are not the driving force in local
addressing.
The requirements I want are simple:
* I want to be able to create prefixes ex-nihilo (from nothing), without
involving the
Mark Smith wrote:
Why are you assuming an ad-hoc network with at the extreme a couple of
hundred nodes ?
and then wrote
I do like the idea of autoconfiguration, but in larger networks, it can
start to work against you - your network can start doing things behind
your back that make it
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
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
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
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
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,
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
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?!!?!
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
Pekka,
Pekka Savola wrote:
1. Shouldn't we first see the requirements for site-local
replacement (and other issues) and not jump straight to the
requirements for local addressing?
Do you mean that the Hain/Templin draft is too generic, or not specific
enough?
3.1 -- Network managers have
On Sun, 24 Aug 2003, Michel Py wrote:
Pekka Savola wrote:
1. Shouldn't we first see the requirements for site-local
replacement (and other issues) and not jump straight to the
requirements for local addressing?
Do you mean that the Hain/Templin draft is too generic, or not specific
Pekka,
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
require specific requirements.
This
Pekka,
We are talking about the way enterprise network managers think about
their networks.
These are people who *will* get fired if their network is seriously
penetrated. In fact, I expect quite a few will be fired in the near
future because of inadequate protection against the current virus
Brian E Carpenter wrote:
Pekka,
We are talking about the way enterprise network managers think about
their networks.
These are people who *will* get fired if their network is seriously
penetrated. In fact, I expect quite a few will be fired in the near
future because of inadequate protection
Leif Johansson wrote:
The added protection you get from a private address space
is isn't worth the bits the configuration is stored in.
Exactly the same as saying that car locks are not worth having because
they're so easy to open that they don't stop anybody. It is true indeed
that any
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.
So there should be no locks on cars until someone
I fear this discussion is headed in the wrong direction as far as the
decisions in this group. You are of course right that filtering (by
private or public addresses) at a border is not sufficient security. But
it DOES remove some unwanted traffic. Is this relevant to local addressing
--
1. Shouldn't we first see the requirements for site-local replacement
(and other issues) and not jump straight to the requirements for local
addressing?
even that seems to me to be asking the question in terms of an assumed
answer.
I want to see the questions asked in terms of real problems,
Pekka Savola wrote:
Hi,
As some others have also commented, I have serious concerns about the
hain/templin draft.
Thank you for providing constructive text, rather than simply complaining.
An observation:
This document seems to take for granted that local-use addressing is
needed.
34 matches
Mail list logo
