Sorry for the typo error
choice is 2) MAY
:-)
- Original Message -
From: "Radhakrishnan Suryanarayanan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, August 19, 2004 2:46 PM
Subject: Re: ICMPv6: Rate Limiting Configuration Per-Node or Per-Interfaces
>
Alex Conta wrote:
The ICMPv6 specification describes the ICMPv6 protocol, a set of ICMPv6
error and informational messages, and some rules and/or suggestions on
handling ICMPv6 messages. Why should "in transit" ICMP messages be
outside its scope?
Others have pointed out that's not how they read
Havard Eidnes wrote:
[...]
Such a rate limiter should of course be
different from the rate limiter used for locally originated
traffic.
Why should?
Because one should (I'd say MUST) differentiate between shaping
locally originated ICMP datagrams and forwarded ICMP datagrams
This still does not elab
This is important point Stig raises and could mean a lot to implementors
of dhcpv6 clients how they implement the coexistence data structures as
a note.
/jim
> -Original Message-
> From: Stig Venaas [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 19, 2004 8:31 AM
> To: Bound, Jim
> Cc
Hi Tim,
Hints Node Reqs I agree. Hints in others I never agreed to at all.
That does not mean that is not the case but lets be clear here people
are running agendas and that is a fact. DHCPv6 will be used by users
and required. If we do draft language that states its MAY and we feel
we have con
On 19 Aug 2004 at 17:14, B wrote:
> Your suggestion looks basically fine, but I want to check one minor
> point:
>
> > Note that when a node joins a multicast address, it typically sends a
> > Multicast Listener Discovery (MLD) report message [RFC2710] for the multicast
> > address. In the case
On Thu, Aug 19, 2004 at 11:10:54AM +1000, Greg Daley wrote:
>
> I'm (currently) leaning toward (2)
>
> 2. M=1 => Solicit/Advertise/Request/Reply is available
> O=1 => Information-request/Reply is available
>
> As Ralph mentioned though, the idea of preventing configuration
> combinations ma
I support
2. M=1 => Solicit/Advertise/Request/Reply is available
O=1 => Information-request/Reply is available
and hope that the flags will remain independent from each other.
Best regards
Peter
IETF IPv6 working group
On Thu, Aug 19, 2004 at 07:59:00AM -0400, Bound, Jim wrote:
> The key is the ongoing debate of stateless vs stateful and members
> working their agendas for their products. The bottom line is the users
> will use stateful and stateless and we need a way to permit that and
> also inform implementor
Hi Jim,
I thought we had reached a concensus that the O/M flags were now only hints,
as part of the IPv6 Node Requirements text (in 4.5.5 and 5.2), and the
2462-bis update, under Section 5.2.
On the requirement to implement stateless support in nodes, it's only a
MAY in the Nodes Requirements d
It is relevant completely to users and implementation your wrong.
But all marked cells for all matrice possibilities for m or o should be permitted.
/jim
> -Original Message-
> From: JINMEI Tatuya / çæéå [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 19, 2004 8:05 AM
> To: Bound, J
> On Thu, 19 Aug 2004 07:54:48 -0400,
> "Bound, Jim" <[EMAIL PROTECTED]> said:
> I did not ever agree to that as a note. If it is set the admin has said
> you should use it the admin is in charge not the host.
Fine, but please note that this particular point is not at all
relevant to the
1 for routers and 2 for hosts.
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of JINMEI Tatuya /
> Sent: Thursday, August 19, 2004 1:41 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: ICMPv6: Rate Limiting Configuration Pe
The key is the ongoing debate of stateless vs stateful and members
working their agendas for their products. The bottom line is the users
will use stateful and stateless and we need a way to permit that and
also inform implementors that both stateful and stateless are required
for clients. That i
I did not ever agree to that as a note. If it is set the admin has said
you should use it the admin is in charge not the host.
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Christian Huitema
> Sent: Wednesday, August 18, 2004 12:10 AM
> To:
> > This does of course not prevent an equipment vendor to provide
> > and an administrator to configure his router to defend against
> > the situation in his network by implementing an optional rate
> > limiter on an interface.
>
> If the router has traffic management per interface, and many if
On Wed, Aug 18, 2004 at 02:51:49PM -0500, [EMAIL PROTECTED] wrote:
> 1) SHOULD
> 2) MAY
> 3) Any of them is fine for you.
MAY...
David.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: htt
On Wed, 18 Aug 2004 [EMAIL PROTECTED] wrote:
> I think everyone agrees that per-interface configuration
> would be a perfect solution and will provide a fine grained
> control to the user. Is there anyone who disagrees with
> this ? (Pekka ??)
My objection to this stems from the fact that an impl
Choice is :
1) MAY
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 19, 2004 1:21 AM
Subject: ICMPv6: Rate Limiting Configuration Per-Node or Per-Interfaces
I think the discussion about the ICMPv6 rate limiting is
going in all directions and
(Confirming a couple of other minor things)
> On Mon, 16 Aug 2004 17:45:52 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> s.5.3: Putting the value of the link local prefix in explicitly makes a
>> potential double maintenance problem.
> I tend to agree. I'll try to revise the text
1) SHOULD
Tom Petch
-Original Message-
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: 18 August 2004 22:22
Subject: ICMPv6: Rate Limiting Configuration Per-Node or Per-Interfaces
In your opinion (no reasoning please), the rate limiting
configu
> On Wed, 18 Aug 2004 17:43:39 +0100,
> "Elwyn Davies" <[EMAIL PROTECTED]> said:
>> global address - an address with unlimited scope. From stateless
>> address autoconfiguration's perspective, it essentially means
>> an address that has larger scope than link-local.
> That would help -
> On Wed, 18 Aug 2004 20:18:27 +0200,
> "Gerrit van Niekerk" <[EMAIL PROTECTED]> said:
>> If there is something we need to care about, it would be that the
>> current text may give an impression that it suddenly starts talking
>> about the MLD implication. So, I'd like to propose a small
One set of answers to your earlier message.. This is probably past
its usefulness.
On Wed, 18 Aug 2004, Alex Conta wrote:
> 1. IP forwarding and ICMP generation is done in one processor, which
> also controls all interfaces. A host with multiple NICs can act as such
> a router.
Sure.
I say
In your previous mail you wrote:
>1. Isn't the notion of "traffic selector" specific to IKEv2? If so,
> should we explicitly say IKEv2 in the example?
> => the term is but not the notion. In fact the notion is from the
> architecture (RFC 2401) when SPD (Security Policy
> On Thu, 19 Aug 2004 12:15:46 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>> => I don't know. Of course this is not ambiguous for me...
>> Perhaps it is time to get an advice from our security area director?
> Perhaps, but I don't know if we can expect an answer considering the
On Wed, 18 Aug 2004, Alex Conta wrote:
> > As Pekka already said that this issue is not just with
> > ICMPv6 but with any bad traffic. For what all bad traffic
> > a router should perform rate limiting for is a general
> > question and should be completely outside the scope of
> > the ICMPv6 Prot
27 matches
Mail list logo
