JINMEI Tatuya wrote:
While working on the rfc2462bis (stateless address autoconf) work,
I've found a new issue, and would like to hear opinions.
The current RFC2462 describes in Section 5.5.3 e) how the valid
lifetime of an autoconfigured address is updated, considering the
avoidance of DoS attack
In your previous mail you wrote:
The current RFC2462 describes in Section 5.5.3 e) how the valid
lifetime of an autoconfigured address is updated, considering the
avoidance of DoS attack with too short lifetimes.
= the DoS attack is about valid lifetime only because when a valid
Hello,
Are there any interface
ioctl() function calls, similar to the SIOCGIFaaa calls, that we could
use to retrieve data about IPv6 interfaces? Thanks!
Kristine Adamson
IBM Communications Server for MVS: TCP/IP Development
Internet e-mail:[EMAIL PROTECTED]
Thanks for the feedback. Was there
ever any discussion in the IPv6 working group in regards to creating a
standard set of ioctl() function calls, similar to the SIOCGIFaaa ioctls,
the could either be used wit IPv6 interfaces, or which could be used with
both IPv4 and IPv6 interfaces (i.e.,
Brian,
If interpreted literally, the following language in the DESCRIPTION
clauses for inetCidrRouteDest and inetCidrRoutePfxLen seems to
prohibit having a non-zero zone index in inetCidrRouteDest:
The values for the index objects inetCidrRouteDest and
inetCidrRoutePfxLen
C. M. Heard wrote:
Brian,
If interpreted literally, the following language in the DESCRIPTION
clauses for inetCidrRouteDest and inetCidrRoutePfxLen seems to
prohibit having a non-zero zone index in inetCidrRouteDest:
The values for the index objects inetCidrRouteDest and
On Wed, Feb 04, 2004 at 07:34:58AM -0800, C. M. Heard wrote:
[...]
It seems to me that an easy fix for this problem would be to alter
the text to exclude the zone index from the comparison. Here is
my suggestion:
The values for the index objects inetCidrRouteDest and
Pekka,
At 12:13 PM 2/3/2004, Pekka Savola wrote:
Inline..
likewise...
On Tue, 3 Feb 2004, Bob Hinden wrote:
The text in the IANA considerations section calls for the IANA to set up a
allocation authority for the centrally assigned ULA prefixes. The exact
details of how to do this (i.e., one
This is a multipart message in MIME format.
--=_alternative 005269DC85256E30_=
Content-Type: text/plain; charset=US-ASCII
Thanks for the feedback. Was there ever any discussion in the IPv6
working group in regards to creating a standard set of ioctl() function
calls, similar to the
If so, it should make sense to recover this part in rfc2462bis.
Possible options include:
1) update the preferred lifetime regardless of whether the valid
lifetime is accepted or not wrt the two-hour rule
2) update the preferred lifetime only when the valid lifetime is
accepted
3)
On Thu, 05 Feb 2004 11:35:53 +0900,
S. Daniel Park [EMAIL PROTECTED] said:
The KAME/BSD implementation behaves as option 1. However, it seems to
me that option 2 makes much more sense because a rejected valid
lifetime indicates a possibility of attack and the other parts of
the
On Wed, 04 Feb 2004 10:17:44 +0100,
Francis Dupont [EMAIL PROTECTED] said:
The current RFC2462 describes in Section 5.5.3 e) how the valid
lifetime of an autoconfigured address is updated, considering the
avoidance of DoS attack with too short lifetimes.
= the DoS attack is about
On Thu, 05 Feb 2004 09:33:38 +1100,
[EMAIL PROTECTED] said:
Thanks for the feedback. Was there ever any discussion in the IPv6
working group in regards to creating a standard set of ioctl() function
calls, similar to the SIOCGIFaaa ioctls, the could either be used wit IPv6
interfaces,
What do you mean by omitted 'two-hour' rule? KAME implements the
two-hour rule just as specified in RFC2462 with one exception:
omitting the following part of 5.5.3 e)
2) If ...(snip) and the
received Lifetime is less than or equal to StoredLifetime,
since this
14 matches
Mail list logo
