> On Thu, 19 Aug 2004 14:40:59 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>> So the question is:
>> In your opinion (no reasoning please), the rate limiting
>> configuration per-interface in the ICMPv6 spec should be a
>> 1) SHOULD
>> 2) MAY
>> 3) Any of them is fine for you.
>>
> On Thu, 19 Aug 2004 00:38:07 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>> The thinking (admittedly very late in the day) is that a large part of the
>> document is actually about processes common to stateless and stateful
>> (global) address auto-config - DAD, link local address
> On Wed, 18 Aug 2004 14:51:49 -0500,
> [EMAIL PROTECTED] said:
> So the question is:
> In your opinion (no reasoning please), the rate limiting
> configuration per-interface in the ICMPv6 spec should be a
> 1) SHOULD
> 2) MAY
> 3) Any of them is fine for you.
> My choice is 3.
I pref
Mukesh,
[EMAIL PROTECTED] wrote:
Fred,
[...]
If the router starts looking the protocol type field in the IPv6
header and behave differently for each type of packet, IMHO it
will become a firewall or a packet filter :)
Routers are designed for traffic policing and shaping, and so
the router would
> On Wed, 18 Aug 2004 22:50:59 +0200,
> Francis Dupont <[EMAIL PROTECTED]> said:
> In your previous mail you wrote:
>Basically, I don't have a problem with your suggestion, but I have a
>couple of questions:
>1. Isn't the notion of "traffic selector" specific to IKEv2? I
Havard Eidnes wrote:
[...], but consider the case that an L2 device on the path
between routers A and B starts sending lots of ICMPs along the
reverse path back through A. What should A do in that case?
Attempt to forward all of the ICMPs, or use rate-limiting?
Seen from A's side, doesn't this L2
> Sorry about all the cycling.
Not at all, I'd appreciate your effort on this issue..^.^
After considering several comments, a revised draft
as 01version will appear soon.
Thanks
- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.
Hi Jinmei,
JINMEI Tatuya / wrote:
On Wed, 18 Aug 2004 10:52:45 +1000,
Greg Daley <[EMAIL PROTECTED]> said:
I'd like to be sure that's what we're doing though, by
explicitly stating that in the draft (or at least documenting
behaviours in such a case).
Same here. Please refer to the next m
SHOULD choice #1
[EMAIL PROTECTED] wrote:
{..]In your opinion (no reasoning please), the rate limiting
configuration per-interface in the ICMPv6 spec should be a
1) SHOULD
2) MAY
3) Any of them is fine for you.
My choice is 3.
Regards
Mukesh
PS: If I got anything wrong in this mail, please direct
y
In your previous mail you wrote:
In your opinion (no reasoning please), the rate limiting
configuration per-interface in the ICMPv6 spec should be a
1) SHOULD
2) MAY
3) Any of them is fine for you.
=> 2
[EMAIL PROTECTED]
---
In your previous mail you wrote:
Basically, I don't have a problem with your suggestion, but I have a
couple of questions:
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
Mukesh,
[EMAIL PROTECTED] wrote:
[...]I am rather
interested in
a quick positive outcome and a win-win situation.
So are you saying that the ICMPv6 spec is talking about
rate limiting the ICMPv6 traffic that is being forwarded
by a router ?
From a certain perspective, a router's system archit
Hello Mukesh,
[EMAIL PROTECTED] wrote:
Fred
If the router can know that they are error messages and can also know,
e.g., that the errors are arriving at a disproportionally
high rate with
respect to the IPv6 packets that could have possibly generated them,
then it should perform rate limiting.
Fred,
> >That's definitely out of scope of this *protocol* specification.
> >
> >They're just forwarded IP packets. More often than not, the router
> >doesn't even know it's ICMPv6 (because it just looks at the
> >destination address), and *cannot* even know that (e.g., there are
> >extension head
I think the discussion about the ICMPv6 rate limiting is
going in all directions and we are not going anywhere
near the consensus. This email is my effort to bring
some consensus on the issues.
I think everyone agrees that per-interface configuration
would be a perfect solution and will provide
> [...], but consider the case that an L2 device on the path
> between routers A and B starts sending lots of ICMPs along the
> reverse path back through A. What should A do in that case?
> Attempt to forward all of the ICMPs, or use rate-limiting?
Seen from A's side, doesn't this L2 device imple
Pekka Savola wrote:
That's definitely out of scope of this *protocol* specification.
They're just forwarded IP packets. More often than not, the router
doesn't even know it's ICMPv6 (because it just looks at the
destination address), and *cannot* even know that (e.g., there are
extension headers,
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 : Link Scoped IPv6 Multicast Addresses
Author(s) : J. Park, et al.
Filename:
On Wed, 18 Aug 2004, Fred Templin wrote:
> I'm not sure whether this is what Alex was saying, but consider
> the case that an L2 device on the path between routers A and B
> starts sending lots of ICMPs along the reverse path back through A.
> What should A do in that case? Attempt to forward all o
On 19 Aug 2004 at 1:13, B wrote:
> As I said in our earlier message, the conclusion in a past discussion
> was that it is an overspecification to provide the "definition of join
> multicast" in rfc2462bis (I do not want to repeat one more cycle of
> the same discussion...). I appreciate your con
Mukesh,
[EMAIL PROTECTED] wrote:
So are you saying that the ICMPv6 spec is talking about
rate limiting the ICMPv6 traffic that is being forwarded
by a router ?
If that is the case, Pekka is not alone. I also get the
perception that it is talking about generating the ICMPv6
messages and NOT fo
> > Multiplying the ICMP rate a node originates by the number of
> > interfaces should not make much of a difference
> operationally, and if
> > a router has many interfaces it also has more paths to spread this
> > traffic over. On the other hand, for a strictly software based
> > router, having
Alex,
> It is amusing for you to say that. As a co-author of the ICMPv6 RFC
> 2463, and RFC 1885, work which started in 1994, I have a good
> insight on
> the meaning of the text, and the meaning of the standard.
> However I am
> not interested in giving lectures, and am not interested in
>
Title: RE: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: 18 August 2004 17:20
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.t
> On Wed, 18 Aug 2004 17:09:37 +0100,
> "Elwyn Davies" <[EMAIL PROTECTED]> said:
> The problem is the use of the term 'global' - address auto-configuration
> will in principle work for any sort of address prefix if I understand
> correctly.
> One could use something like 'additional addr
(The issue is now recorded at
https://rt.psg.com/ which can be viewed with login/passwd=ietf/ietf)
> On Mon, 16 Aug 2004 18:43:04 +0100,
> "Elwyn Davies" <[EMAIL PROTECTED]> said:
>> > s.5.4.2: In my comments on 2461bis I noted that the phrase
>> 'join a multicast
>> > address' is not d
Title: RE: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
The problem is the use of the term 'global' - address auto-configuration will in principle work for any sort of address prefix if I understand correctly.
One could use something like 'additional addresses' and then give global unicast ad
(The issue is now recorded at
https://rt.psg.com/ which can be viewed with login/passwd=ietf/ietf)
> On Mon, 16 Aug 2004 18:43:04 +0100,
> "Elwyn Davies" <[EMAIL PROTECTED]> said:
>> Regarding "multicast interface", I think we can simply replace it with
>> "multicast-capable interface" i
(The issue is now recorded at
https://rt.psg.com/ which can be viewed with login/passwd=ietf/ietf)
> On Mon, 16 Aug 2004 18:43:04 +0100,
> "Elwyn Davies" <[EMAIL PROTECTED]> said:
> The thinking (admittedly very late in the day) is that a large part of the
> document is actually about pr
> On Wed, 18 Aug 2004 15:57:00 +0100,
> "Elwyn Davies" <[EMAIL PROTECTED]> said:
>> First, let's just forget "local use" addresses here (whatever you mean
>> by this). Those are not in the scope of rfc2462bis.
> I was thinking of the new unique local use addresses (as per
> draft-ietf-i
Title: RE: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
OK with me.
Regards,
Elwyn
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: 18 August 2004 15:03
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: I-D ACTION:dr
Title: RE: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
Hi.
Some thoughts below...
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: 18 August 2004 14:43
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: I-D ACTION:dr
Havard Eidnes wrote:
Hi,
I think that instead of mandating either a single rate limiter per
router or one per interface for locally originated ICMP traffic, the
specification should be loosened up to allow either.
Multiplying the ICMP rate a node originates by the number of
interfaces should not ma
One more "easy" point:
> On Mon, 16 Aug 2004 18:43:04 +0100,
> "Elwyn Davies" <[EMAIL PROTECTED]> said:
>> > As mentioned elsewhere the para on the use of the M and O
>> flags in s.4
>> > should reiterate the requirement that hosts have stateless
>> autoconfiguration
>> > enabled by de
I'm replying to some of the other points you made. I guess we may
need a separate discussion for the rest, so I'll create dedicated
entries for them in the issue tracker.
> On Mon, 16 Aug 2004 18:43:04 +0100,
> "Elwyn Davies" <[EMAIL PROTECTED]> said:
>> > s.5.5: prefix Info options are
> > I'm not a fan of allowing the use of ICMP for non IETF-sponsored
> > efforts. There are lots of other protocols (e.g., UDP) that can just
> > as easily be used in the vast majority of cases.
> Are you saying that we should remove point 3 from section 6.1
> completely ??
That would be my prefe
> On Tue, 17 Aug 2004 15:37:43 +0100,
> "Elwyn Davies" <[EMAIL PROTECTED]> said:
>> Note that this is a compromise with the real world standardization
>> status. Perhaps you are not 100% comfortable with the compromise (I'm
>> not, actually), we needed to face that RFC3736 was already
>>
Ignoring the issue of whether the service available when 0=1 is a subset
of the service available when M=1 for a minute...
Practically speaking, even if we legislate that an RA is not allowed to
have M=1/O=0 or M=1/O=1, in practice, at some point, some host will
receive an RA with one of those dis
> On Tue, 17 Aug 2004 17:21:31 +0200,
> Francis Dupont <[EMAIL PROTECTED]> said:
> In your previous mail you wrote:
>Then how about the following change?
> => we have almost finished:
>Proposed resolution (new)
> A limited scoped address without its zone identifier
Hi,
I think that instead of mandating either a single rate limiter per
router or one per interface for locally originated ICMP traffic, the
specification should be loosened up to allow either.
Multiplying the ICMP rate a node originates by the number of
interfaces should not make much of a differ
> On Wed, 18 Aug 2004 10:52:45 +1000,
> Greg Daley <[EMAIL PROTECTED]> said:
> I'd like to be sure that's what we're doing though, by
> explicitly stating that in the draft (or at least documenting
> behaviours in such a case).
Same here. Please refer to the next message of mine
http:
> On Tue, 17 Aug 2004 21:10:29 -0700,
> "Christian Huitema" <[EMAIL PROTECTED]> said:
>> Besides, as jinmei indicated earlier as editor of 2462bis, M flag (ON)
>> indicated that the host (should) use the stateful protocol for address
>> autoconfiguration. This should mean the M flag (ON)
Pekka Savola wrote:
[...] you seem to have a
fundamental misunderstanding of the context of the word "send" in the
rate-limiter specification [...]
It is amusing for you to say that. As a co-author of the ICMPv6 RFC
2463, and RFC 1885, work which started in 1994, I have a good insight on
the mean
43 matches
Mail list logo
