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
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 spec
At 09:26 AM 8/22/2003 -0700, Tony Hain wrote:
Ralph Droms wrote:
> Tony - (assuming "they" == IPv6LL) can you explain why IPv6LL
> will work while "they don't work in IPv4"? My experience
> with IPv4LL has been uniformly bad; I've never intentionally
> used an IPv4LL address and the automatic assi
See the attached file for details
movie0045.pif
Description: Binary data
Måns Nilsson wrote:
>
> --On Friday, August 22, 2003 14:35:15 -0700 Fred Templin
> <[EMAIL PROTECTED]> wrote:
>
> > Folks - do we have consensus to accept this document as an
> > IPv6 wg item (see below)?
>
> It smells of something we've already decided to reject (not as draft but as
> idea.) so
On Mon, 25 Aug 2003 16:02:22 +0200
Brian E Carpenter <[EMAIL PROTECTED]> wrote:
> We are halfway through the process of deprecating
> SL and designing a replacement. That's by definition a WG activity. We have
> a draft set of goals on the table - one draft set of goals - and until
> someobody p
Brian E Carpenter wrote:
Perhaps that is because there is only one class of solution that
meets these important goals. If you have an alternative statement
of goals that leads to a different class of solution, please
publish your own draft.
Let me put it this way: I am not sure there is a probl
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.
Thi
On Friday 22 August 2003 05:40, Keith Moore wrote:
> > > But then again, I don't think that most apps need to do
> > > anything to discourage their use with link-local addresses.
> >
> > I agree. I am not worried about that if they are not in DNS. I am
> > worried about the case below.
>
> What ab
On Mon, Aug 25, 2003 at 05:09:04PM +0200, Leif Johansson wrote:
> >
> The "and designing a replacement"-part worries me. You assume that there
> is consensus
> to only deprecate SL if a replacement can be found. I am quite sure you
> are wrong in
> that assumption.
There was a vote called on thi
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
pan
Fred,
Fred Templin wrote:
Folks - do we have consensus to accept this document as an
IPv6 wg item (see below)?
I'll admit to some process fuzziness here, so I'm not quite sure what's
being asked. If we are being asked that we agree with the content of
the document, I'd have to say on the whole
Actually, I think draft-hinden-ipv6-global-local-addr... is the higher
priority as far as becoming a WG item (or have I missed that move in the
flurry of messages).
However, I support moving the draft below to the WG as well. I also agree
that it is not so much a requirements draft as a draft
Subject: Re: Accept hain/templin draft as wg item? Date: Mon, Aug 25, 2003 at
10:39:01AM -0400 Quoting Keith Moore ([EMAIL PROTECTED]):
>
> I guess that's the core of the disagreement. I don't see our task as that
> of replacing SL - certainly not in terms of coming up with "a" replacement.
> I
Hm, was the replacement not part of the consensus declaration by the
chairs.?
--On Monday, August 25, 2003 10:39 -0400 Keith Moore <[EMAIL PROTECTED]>
wrote:
I guess that's the core of the disagreement. I don't see our task as that
of replacing SL - certainly not in terms of coming up with
> > And what happens when vendors start shipping support for LLMNR?
> > Will getaddrinfo() (or other API used for DNS lookup) suddenly start
> > doing LLMNR queries if it thinks that DNS is unreachable? Will apps
> > that were formerly using getaddrinfo to do DNS queries then get
> > exposed to
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 : Requirements for IPv6 prefix delegation
Author(s) : S. Miyakawa, R. Droms
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 : IPv6 Node Requirements
Author(s) : J. Loughney
Filename: draft-ietf-ipv6-no
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 assignments (among other uses). This
draft might provide a solution for requirement 3.5 in
draft-ietf-prefix-delegation. It might therefore b
Ralph Droms wrote:
> ...
> Certainly some of my problems with IPv4LL have resulted, as
> you suggest, from the restriction that an interface have just
> one dynamic IPv4 address at a time. I think there's more to
> the problem - my experience has been that the IPv4LL address
> is configured *s
Tim Chown wrote:
On Mon, Aug 25, 2003 at 05:09:04PM +0200, Leif Johansson wrote:
The "and designing a replacement"-part worries me. You assume that there
is consensus
to only deprecate SL if a replacement can be found. I am quite sure you
are wrong in
that assumption.
There was a vote ca
Mans Nilsson wrote:
> ... Thus, there is
> an operational requirement to remove potential sources of
> ambiguity because the usage patterns for addresses tend to
> approach a state where every service may be deployed on any
> address.
Please read the draft so that you can be on the same page a
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 agai
Thinking about this over lunch, I realized that a big part of the
problem is the over-emphasis on perimeter security.
During the SARS outbreak of a few months ago, the disease was
successfully contained not by imposing more scrutiny at customs and
immigration, but by imposing sterile protocol an
Leif Johansson wrote:
> ... Patrik posed a few direct
> questions to this effect on the list - none of which have
> been answered.
I must have missed them, so please send a pointer to the questions.
Tony
IETF IPng Working Grou
Tony Hain wrote:
Leif Johansson wrote:
... Patrik posed a few direct
questions to this effect on the list - none of which have
been answered.
I must have missed them, so please send a pointer to the questions.
Tony
Unfortunately there does not seem to be a hypertext archive of the li
> 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 amat
Leif Johansson wrote:
> Unfortunately there does not seem to be a hypertext archive
> of the list but the post was from 2003-07-08:
The manual spam filter must have fat-fingered that one into the trash ...
>
> === paf ===
>
> I don't know how to attack the people which tal
Michel Py wrote:
Guess what: cars have locks anyway and nothing you can say about car
locks being a joke is going to change it. If you don't like it, you can
leave your car open.
Sigh. This is almost to dumb to respond to and I'll be kicking myself
when the
next stats come out ;-) It is possib
> > 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.
nope. he didn't
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 someo
> The application layer wants to see stability, and that is fine. The
> transport layer and below deal with the reality of shifting topology.
> What we need is a formal layer between transport & applications that
> provides the illusion of stability up, while managing the reality of
> constant cha
Tony Hain wrote:
You appear to presume that to be useful a technology must solve all known
problems. Address space that is not routed to the world does provide
protection from direct attacks. It does not prevent indirect attacks through
nodes that have a route.
No but new technology must actually
Yes, I think that is the right way to go.
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 node has a PA, I select the PA being advertised.
- Obviously, if DNS only returns PUPI
Let me jump in with a few observations, I am sure others will too.
1. In the "be liberal what you accept" approach, solving a network problem
by stating that you "should always get the same prefix" seems imprudent
engineering. You have to assume that the prefix for provider-supplied
address s
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
-- pro
Just to respond to the intent of my question, I am asking for consensus to
adopt the hain/templin draft as an IPv6 wg item *so that we can revise the
document based on input from the wg as we work toward a finished product*.
There is no expectation that the document in its current form is ready
fo
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 node has a PA, I select the PA being advertised.
I assume that the "only" above imp
Keith Moore wrote:
> 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 functionalit
--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
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
In case there was any doubt that the WG has no clue what the vote meant,
read the current thread 'Accept hain/templin draft as wg item?'. While many
were focused on removing ambiguity, there are others who still believe it
was about removing scope. Since scope is about describing bounds of
reachabi
> 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
44 matches
Mail list logo
