On Wed, 4 Feb 2004, Bob Hinden wrote:
> > > I agree this could be stated better. I think it would be good to
> > > change it to "Any router that is used between sites", as it is
> > > not the routing protocols doing the filtering, but the router based
> > > on it's configuration.
> >
> >But th
> Is it only I that find it odd that talking about Multicast DNS
> is viewed to be in-scope for this document, while talking about the
> applicability issues for the addresses *defined by this document*
> is stated to be out of scope??
I agree with Erik on this point.
> > >For future study na
>From what I have read so far, the monetary payment appears to be one of
the weakest point of the proposal. I suggest that the monetary
consideration in the draft be removed, and that the precise method used
to implement the registration be left to the registry. Specifically, I
suggest in section "
Hi Jinmei,
JINMEI Tatuya / wrote:
On Thu, 5 Feb 2004 17:55:08 +0200,
Markku Savela <[EMAIL PROTECTED]> said:
It should be noted that the Neighbor Solicitation is usually not the
first message. As stated above, the sending node must join the
solicited-node multicast address prior to sending
I changed the subject because I believe this is a separate issue.
> On Thu, 5 Feb 2004 17:40:44 -0800 (PST),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> This issue was originally posted by Ken Powell in February 2000:
>> I was able to force the preferred lifetime to zero by reconfiguri
> On Thu, 5 Feb 2004 17:40:44 -0800 (PST),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> My suggestion to the second point is that we should also ignore the
>> preferred lifetime if the valid lifetime is ignored due to the
>> two-hour rule.
> In my example of the incorrectly advertised pr
> +router - a node that forwards IPv6 packets not explicitly
> + addressed to itself. [See Note below].
> +...
> +Note: it is possible, though unusual, for a device with multiple
> +interfaces to be configured to forward non-self-destined packets
> +arrivi
Erik Nordmark wrote:
So do we or do we not want to
1. specify the per-interface router definition
2. specify how RFC 2461 (and 62) behave on a multihomed node
Well, from RFC 2460 we have:
+router - a node that forwards IPv6 packets not explicitly
+ addressed to itself.
Is it only I that find it odd that talking about Multicast DNS
is viewed to be in-scope for this document, while talking about the
applicability issues for the addresses *defined by this document*
is stated to be out of scope??
Erik
> >For future study names with Local IPv6 addresses may b
> So my first point is that we should clearly specify how the preferred
> lifetime is updated in 5.5.3 e) of rfc2462bis, mainly for normal
> cases. My second point is what we should do about the preferred
> lifetime when the valid lifetime is ignored due to the two-hour rule.
>
> My suggestion to
> Additionally, adopting this definition also opens up the possibility
> of a "half-host, half-router" node, like:
>
> --(I1)Node(I2)---
>(I3)
> |
> |
>
> where I1 and I2 are "normal" interfaces for which the node is ac
> 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) leave this as implementation dependent
> The KAME/BSD implementation behaves as option 1
The list of changes to the previous drafts can
be found in the document itself. The biggest
recent change was the modification of objects in
the ipAddressTable to allow for the creation or
modification of rows in the table.
There is one outstanding change that has been agreed
to but not incorpor
Sorry for bothering you all by the bunch of messages. This is the
last one for now. (I'm afraid I'll be the "winner" of this week:-)
The followings are the issues for rfc2462bis that are still open.
I don't have particular proposals for them right now (particularly for
the last two), and I'm afra
This issue was originally posted by Ken Powell in February 2000:
== begin citing
I recently ran some experiments in our lab to see how our IPv6
implementation responds to sudden network topology changes.
In the course of these experiments, I caused
> On Thu, 5 Feb 2004 17:55:08 +0200,
> Markku Savela <[EMAIL PROTECTED]> said:
>> It should be noted that the Neighbor Solicitation is usually not the
>> first message. As stated above, the sending node must join the
>> solicited-node multicast address prior to sending the Neighbor
>> Sol
> To address the following issue for rfc2462bis:
>
> There is conflict with the Multicast Listener Discovery
> specification about random delay for the first packet. The address
> autoconfiguration requires a random delay for a DAD packet if it
> is the first packet from th
To address the issue "the requirement that the interface SHOULD be
disabled upon DAD failure is too strong", I simply added the following
line to Section 5.4.5:
An implementation MAY try an automatic recovery technique
from this failure and re-enable the interface.
in the proposed resolutio
RFC 2460 provides this note in the terminology section:
Note: it is possible, though unusual, for a device with multiple
interfaces to be configured to forward non-self-destined packets
arriving from some set (fewer than all) of its interfaces, and to
discard non-self-destined packets arr
There was an issue about how much we should allow a router (not a
host) to use the RFC2462 spec to configure itself. Specifically,
a) if a router can configure a global address by stateless autoconf
b) if a router can configure a link-local address in a way described
in RFC 2462
To address the following issue for rfc2462bis:
There is conflict with the Multicast Listener Discovery
specification about random delay for the first packet. The address
autoconfiguration requires a random delay for a DAD packet if it
is the first packet from the node, but
FYI.
-- Forwarded message --
Date: Mon, 02 Feb 2004 10:48:25 -0500
From: [EMAIL PROTECTED]
To: IETF-Announce: ;
Subject: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting
in Seoul, Korea
There are two (2) Internet-Draft cutoff dates for the 59th IETF Meeting in
To address rfc2462bis issue 271, "An implementation may want to use
stable storage for autoconfigured addresses", I've added the following
new (sub)section:
5.7 Retaining Configured Addresses for Stability
It is reasoanble that i
[EMAIL PROTECTED] wrote on 02/04/2004
11:04:33 PM:
> > 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, simila
Hello,
I'm now working on the rfc2462bis document, and I've done the work for
most of the issues I raised in the previous draft and presented in
Minneapolis with my own proposed resolutions (which should be
discussed and agreed by the wg, of course). I've revised the
rfc2462bis text with the reso
25 matches
Mail list logo
