This issue addresses RFC 2461's assumptions about
securing ND messages.
The following is needed:
- explain context in which IPSec can be used to secure NDP messages.
This should include a reference to the SEND work.
- Expand Security Considerations section to discuss more security
threats def
Zefram <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|>As I recall, at one point someone set up a proof-of-concept auto-allocator
|>just to show how easy it was to hand out prefixes. It was shut down very
|>quickly. :( I'd like to know who ``requested'' this...
|
|As I recall, it was claiming
Dan Lanciani wrote:
>As I recall, at one point someone set up a proof-of-concept auto-allocator
>just to show how easy it was to hand out prefixes. It was shut down very
>quickly. :( I'd like to know who ``requested'' this...
As I recall, it was claiming to actually allocate prefixes. I don't
i
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 Stateless Address Autoconfiguration
Author(s) : S. Thomson
Filename: d
Zefram <[EMAIL PROTECTED]> wrote:
|The allocation bitmap would be 128GiB. That fits onto one current
|commodity hard disk. Are we really quibbling over who's going to have
|to pay for eternal reliable storage of such a trifling dataset?
Not really. It's just folks grasping at straws in a despe
Alain Durand <[EMAIL PROTECTED]> wrote:
|On Feb 8, 2004, at 3:02 PM, Dan Lanciani wrote:
|>
|> In the past we were unable to come up with a value for ``long enough''
|> which
|> is in any meaningful way different from ``forever.''
|
|There is a simple business model to solve this problem:
|long e
On Tue, 2004-02-10 at 13:38, JINMEI Tatuya / çæéå wrote:
> I've submitted a new revision of the rfc2462bis draft:
> draft-ietf-ipv6-rfc2462bis-00.txt
>
> I expect a certain amount of delay before the draft is ready at the
> official I-D archive, so I put a copy of the draft at the following URL:
Hi Jinmei,
(B
(B> The new revision revised this section as follows:
(B>
(B> 5.4.5 When Duplicate Address Detection Fails
(B>
(B>A tentative address that is determined to be a duplicate as described
(B>above MUST NOT be assigned to an interface and the node SHOULD log a
(B>syst
> From: Soliman Hesham <[EMAIL PROTECTED]>
> What should a node do upon reception of a prefix option with the prefix
> length set to a value >64?
...
> 4. Leave this field as is and design a mechanism that
> allows the host to form an address based on the
> length of the interface identifier (i.e
I've submitted a new revision of the rfc2462bis draft:
draft-ietf-ipv6-rfc2462bis-00.txt
I expect a certain amount of delay before the draft is ready at the
official I-D archive, so I put a copy of the draft at the following URL:
http://www.jinmei.org/draft-ietf-ipv6-rfc2462bis-00.txt
Any commen
What should a node do upon reception of a prefix option with the prefix
length set to a value >64?
The issue can be stated more accurately to say:
What should a host do upon reception of a prefix option with the prefix
length set to a value != 64?
So far I haven't received any comments on this i
> On Tue, 10 Feb 2004 20:31:19 +0900 (JST),
> [EMAIL PROTECTED] (Jun-ichiro itojun Hagino) said:
>> 3. What happens if someone builds a stack from multiple vendors
>> (e.g. MLD from vendor X and NDP from vendor Y)?
> this is "someone"'s responsibility to ensure the documented behav
> 3. What happens if someone builds a stack from multiple vendors
> (e.g. MLD from vendor X and NDP from vendor Y)?
this is "someone"'s responsibility to ensure the documented behavior,
IMHO. it is not a concern for standard document (no need to document).
itojun
--
JINMEI wrote:
On Mon, 09 Feb 2004 06:24:26 -0500,
Brian Haberman <[EMAIL PROTECTED]> said:
I think what Jari asked was not a modification to the semantics
of reporting group joins.
I think that what Jari proposed was actually that we delay DAD
(which entails both the operation of beginning lis
Jinmei,
5.4.5 When Duplicate Address Detection Fails
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 from an interface iden
> On Mon, 09 Feb 2004 06:24:26 -0500,
> Brian Haberman <[EMAIL PROTECTED]> said:
>> I think what Jari asked was not a modification to the semantics
>> of reporting group joins.
>>
>> I think that what Jari proposed was actually that we delay DAD
>> (which entails both the operation of be
Tim Chown wrote:
>With 1,000 billion entries, it might also become a large database...
The allocation bitmap would be 128GiB. That fits onto one current
commodity hard disk. Are we really quibbling over who's going to have
to pay for eternal reliable storage of such a trifling dataset?
When thi
17 matches
Mail list logo
