> > Proposed resolution: write "MAY be disabled" instead.
>
> Um, I'd suggest that this by itself isn't really all that helpful. It
> might help to add some more explanatary text together with
> recommendations on what to do. E.g.,
>
> - should an implementation just configure the address and u
Thomas,
> One of the original motivations for disabling an interface if DAD
> fails for the LL address is that if you are running DAD on a LL
> address generated using the EUI-64 format, in the absence of a DOS
> attack, if DAD fails, that really means duplicate ethernet addresses
> are in use. In
One more point:
One of the original motivations for disabling an interface if DAD
fails for the LL address is that if you are running DAD on a LL
address generated using the EUI-64 format, in the absence of a DOS
attack, if DAD fails, that really means duplicate ethernet addresses
are in use. In t
> Proposed resolution: write "MAY be disabled" instead.
Um, I'd suggest that this by itself isn't really all that helpful. It
might help to add some more explanatary text together with
recommendations on what to do. E.g.,
- should an implementation just configure the address and use it
anyway
I think we're missing the point.
There is a perceived need by "many" operators for an address space that can
be used for 'local' use, where 'local' is 'not part of the global
internet'. We can argue until the cows come home whether any given possible
use for such a space is good or bad, but the f
Keith,
> it would really seem odd to me to use a "local address" to talk to a
> host that is halfway across the world.
I read my local paper (from West Caldwell, NJ) on line at work
(Helsinki, Finland). I still call it my local paper ...
John
> that, and I'm concerned that people will think t
even the word "local" might be too much. it is not out of the
question
for networks from all over the world to agree to exchange traffic
using
GUPIs and/or PUPIs.
Local might still be OK, if you think that the addresses have 'local'
relevance
not global relevance. One possible meaning of local
Keith,
> >> So - yes, we need addresses that can be easily allocated
> for local use
> >> (and perhaps for other purposes also), but they should not
> carry with
> >> them any assumptions about the degree of locality or proximity,
> >> trustworthiness, filtering, or policy.
> >
> > I agree. I t
On Wednesday, November 12, 2003, at 03:05 PM,
<[EMAIL PROTECTED]> wrote:
Keith,
So - yes, we need addresses that can be easily allocated for local use
(and perhaps for other purposes also), but they should not carry with
them any assumptions about the degree of locality or proximity,
trustworth
Hi all,
> > but then, if we change it to MAY, what is the point in running DAD
> > process? if you do not disable interface (or the address on the
> > interface) the owner of the same address will get confused,
> > peers of the address get confused, you will do bad things to the
>
Jun-ichiro itojun Hagino wrote:
Well, there are many networks that are open to the general public, for
example wifi networks at airports.
It is true that a bad guy on-link can do a lot of harm, some of which
can be alleviated by SEND. However, most of other attacks require a
constant stream of
> > It is true that a bad guy on-link can do a lot of harm, some of
which
> > can be alleviated by SEND. However, most of other attacks require a
> > constant stream of packets, and increase the risk that the attack
will
> > be detected and traced. The recommendation to turn off the interface
> > a
> Well, there are many networks that are open to the general public, for
> example wifi networks at airports.
>
> It is true that a bad guy on-link can do a lot of harm, some of which
> can be alleviated by SEND. However, most of other attacks require a
> constant stream of packets, and increase
Jun-ichiro itojun Hagino wrote:
my suggestion is to leave it SHOULD.
you didnt justify why. makes no sense on an unprotected network.
i did. you did not quote my previous line.
agree completely. if you allow enemy to be on-link you are dead.
my suggestion is to leave it SH
Jun-ichiro itojun Hagino wrote:
my suggestion is to leave it SHOULD.
you didnt justify why. makes no sense on an unprotected network.
i did. you did not quote my previous line.
agree completely. if you allow enemy to be on-link you are dead.
my suggestion is to leave it S
> >>my suggestion is to leave it SHOULD.
> >you didnt justify why. makes no sense on an unprotected network.
>
> i did. you did not quote my previous line.
>
> >>agree completely. if you allow enemy to be on-link you are
dead.
> >>my suggestion is to leave it SHOULD.
>
>
--- Forwarded Message
From: Leslie Daigle <[EMAIL PROTECTED]>
To: Tony Hain <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Date: Wed, 12 Nov 2003 14:40:06 -0500
Subject: IAB Response to your appeal of October 9, 2003
User-Agent: Mozilla/5.0 (X11; U; Linux i686;
>> my suggestion is to leave it SHOULD.
>you didnt justify why. makes no sense on an unprotected network.
i did. you did not quote my previous line.
>> agree completely. if you allow enemy to be on-link you are dead.
>> my suggestion is to leave it SHOULD.
this i
Jun-ichiro itojun Hagino wrote:
my suggestion is to leave it SHOULD.
you didnt justify why. makes no sense on an unprotected network.
Vijay
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https:
> On Wed, 12 Nov 2003, Christian Huitema wrote:
> > The section "5.4.5 When Duplicate Address Detection Fails" currently
> > says:
> >
> >A tentative address that is determined to be a duplicate as described
> >above, MUST NOT be assigned to an interface and the node SHOULD log a
> >sy
It was suggested I send text on my suggestion for clarification in
draft-ietf-ipv6-deprecate-site-local-01.txt.
After the second paragraph in section 4 I suggest adding something about
the intent:
The intent is that any existing code in implementations that
assign any special mea
On Wed, 12 Nov 2003, Christian Huitema wrote:
> The section "5.4.5 When Duplicate Address Detection Fails" currently
> says:
>
>A tentative address that is determined to be a duplicate as described
>above, MUST NOT be assigned to an interface and the node SHOULD log a
>system managemen
Christian,
> The section "5.4.5 When Duplicate Address Detection Fails" currently
> says:
>
>A tentative address that is determined to be a duplicate as described
>above, MUST NOT be assigned to an interface and the node SHOULD log a
>system management error. If the address is a link
Keith,
> So - yes, we need addresses that can be easily allocated for local use
> (and perhaps for other purposes also), but they should not carry with
> them any assumptions about the degree of locality or proximity,
> trustworthiness, filtering, or policy.
I agree. I think that in documenti
Hi,
With reference to the roles of the M and O bits in RA
messages, Jinmei mentioned that with these bits we
should reference the DHCPv6 RFC.
I made the statement at Wednesday's session that we may need
a reference to the Stateless DHCPv6 document which is not
an RFC.
After talking to Ralph, I
The section "5.4.5 When Duplicate Address Detection Fails" currently
says:
A tentative address that is determined to be a duplicate as described
above, MUST NOT be assigned to an interface and the node SHOULD log a
system management error. If the address is a link-local address
formed
These are comments on the document rather than on Tony's presentation
yesterday
I think the notion of "local-use" address conflates several different
things that are better treated as separate subjects. Even if one
accepts all of these as valid problems (which I don't), it's not clear
that th
Yes, it's me again - hopefully one last time. I took out a bit too much in
my last iteration on the document. I have added the following new text
under "Sending Packets:"
"If the packet is 1280 bytes in length and it contains an IPv6 fragment header, the tunnel interface encapsluates the
For those who were not in the room this evening, my comments were that
the
complaints on the list about the draft fall into a couple of broad
categories:
One class basically intends to tell people how to run their networks.
The
IETF defines how the protocols work, not how individual networks are
I have one more update to share on this document. It is found at:
www.geocities.com/osprey67/tunnelmtu-05.txt
Changelog is below:
Fred Templin
[EMAIL PROTECTED]
Appendix A. Changelog o Removed support for IPv4 fragmentation to save state; eliminated control message overhead.
Fred
I cannot say which of Tony's points I agree on and which I still
might have some uncertainties. But, I will say that our document
presents Scenarios and Goals that no one seems to be disputing
as a service to the community and these will not go away.
I will also say that I think it's time for us
Tony keeps making statements like the one in the subject line of this
message. This message attempts to explain why such statements are not
helpful generalizations.
IETF can, does, and should make various kinds of statements about how
people run IP networks. Most of the time, these take the f
For those who were not in the room this evening, my comments were that the
complaints on the list about the draft fall into a couple of broad
categories:
One class basically intends to tell people how to run their networks. The
IETF defines how the protocols work, not how individual networks are r
33 matches
Mail list logo
