On Wed, 25 May 2005 21:06:53 -0400,
Soliman, Hesham [EMAIL PROTECTED] said:
This comment was concerned with removing
the not the preceded INCOMPLETE. Peter (who raised the comment)
said he's happy with just the removal, which was a typo. So what else
needs to be done?
I thought I had
Hello,
In your IESG comments on draft-ietf-ipv6-rfc2462bis-07.txt, you said:
RFC 3756 says that IPsec really does not work for neighbor
discovery. Even if it does work in some cases, there is not
enough detail in this document to say how to use it. SEND
is the answer, of course.
On Thu, 2 Sep 2004 23:29:09 +0200 ,
Elwyn Davies [EMAIL PROTECTED] said:
In Section 5.3:
A link-local address is formed by prepending the well-known
link-local prefix [RFC3513] (of appropriate length) to the interface
identifier. If the interface identifier has a length of N
On Thu, 12 Aug 2004 15:23:23 +1000,
Greg Daley [EMAIL PROTECTED] said:
It's important to relize though that a host doesn't invoke
RFC 3736 procedures though. The host only cares that it wants to
do an Information-Request. 3736 is an implementation hint for
DHCPv6 servers and relays, not
On Wed, 11 Aug 2004 14:16:03 +1000,
Greg Daley [EMAIL PROTECTED] said:
This is a bit of a rant.
Please accept my apologies. I'm quite concerned by
the form of the document at the moment, although I
think that the function needs to be available.
No need to apologize, I know the proposed
On Wed, 16 Jun 2004 04:05:06 -0400,
Soliman Hesham [EMAIL PROTECTED] said:
So I added one sentence to the description of the prefix
length. The text now reads:
Prefix Length 8-bit unsigned integer. The number of leading bits
in the Prefix that are valid. The value
On Tue, 15 Jun 2004 15:45:31 -0400,
[EMAIL PROTECTED] said:
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
On Tue, 15 Jun 2004 09:31:51 -0400,
Soliman Hesham [EMAIL PROTECTED] said:
(I'd personally avoid using the magic number of 64, but anyway)
= Why? It's a reality, at least for 2462.
Even RFC2462 says the length is typically 64 bits, and does not
assume the number as an invariable constant.
On Tue, 8 Jun 2004 08:38:19 +0300 (EEST),
Pekka Savola [EMAIL PROTECTED] said:
Assuming I'm correct for both the questions, I'd like to propose to
revise the logic in Section 5.5.3 as follows:
a) Check for the Autonomous flag
b) Ignore the link-local prefix
c) Check for the case of
On Tue, 08 Jun 2004 10:07:41 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
It seems to me that this specification allows (e.g.,) the prefix
::/0 to update the lifetimes all existing addresses (which may even
include link-local addresses), since ::/0 matches any addresses.
Is this the
On Tue, 8 Jun 2004 11:19:24 -0700 (PDT),
Erik Nordmark [EMAIL PROTECTED] said:
It seems to me that this specification allows (e.g.,) the prefix
::/0 to update the lifetimes all existing addresses (which may even
include link-local addresses), since ::/0 matches any addresses.
Is this the
On Tue, 1 Jun 2004 16:16:03 +1000,
Nick 'Sharkey' Moore [EMAIL PROTECTED] said:
3) IMHO, section 3.3 on Address Generation is largely redundant or downright
inappropriate. It describes a few useful things, but also goes on to
specify how to regenerate the addresses if a conflict is found.
I've not seen direct comments on the proposed text (I've seen a
side discussion regarding this topic, so I know at least a few people
have been aware of the proposal).
I've already edited my local copy of rfc2462bis based on the proposal,
which will soon be submitted (probably within a week). It
On Sat, 29 May 2004 07:21:53 +0900 (JST),
[EMAIL PROTECTED] (Jun-ichiro itojun Hagino) said:
Just a refresh of my opinion on this (so that people don't forget):
Sending MLD reports on link local multicast groups is silly, and
SHOULD NOT be required.
It is not nice to require
On Sat, 29 May 2004 12:22:13 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
Though I personally think the last sentence is too much in the scope
of rfc2462bis. But I can live with either
1. do nothing on this in rfc2462bis,
2. add the above note without the further notice, or
3. add the
On Mon, 31 May 2004 10:05:38 +0200,
Gerrit van Niekerk [EMAIL PROTECTED] said:
I find the language somewhat confusing. This is what I undestand the paragraph
to say:
Note that it is possible that there is no router on the link in this
sense, but there is a node that has the ability
Hello,
I'd now like to resume the discussion on another set of outstanding
issues for rfc2462bis: DAD related ones.
Based on the past discussion, I'd like to propose the following basic
approach:
- basically, strongly recommend to perform DAD all unicast addresses
(use much stronger
On Fri, 28 May 2004 20:24:31 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
I'd now like to resume the discussion on another set of outstanding
issues for rfc2462bis: DAD related ones.
Based on the past discussion, I'd like to propose the following basic
approach:
- basically, strongly
On Fri, 28 May 2004 15:16:42 +0200,
Gerrit van Niekerk [EMAIL PROTECTED] said:
I am a bit new to this list and could not pick up the specific thread for issue
337, but it looks to me like the sending of the NS should be delayed and not
the joining of the solicited-node multicast address.
On Wed, 26 May 2004 13:34:12 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
I am still of the belief that limiting the routing prefix to 64 bits is a
shortsighted design choice that will limit the lifetime and applicability
of IPv6. Anything we can do to discourage the notion that an
On Tue, 25 May 2004 08:26:57 +0200,
Christian Strauf (JOIN) [EMAIL PROTECTED] said:
We might add a further notice on the suggested configuration:
Thus, a node that has the ability of forwarding should be configured
to send router advertisements unless there is a strong reason to not
do
On Thu, 27 May 2004 08:50:45 +0200,
Christian Strauf (JOIN) [EMAIL PROTECTED] said:
Besides, this part of the specification seems a bit too specific about
stateful autoconfiguration, considering we are now going to separate
particular behavior on the stateful configuration part from
On Fri, 28 May 2004 23:49:48 -0400,
Keith Moore [EMAIL PROTECTED] said:
Just checking: is this an agreement or a disagreement on the proposed
text for rfc2462bis, or is this just an opinion on the (seemingly)
fixed constant of the IFID/prefix length?
In any event, the proposed text does
I've found one more thing that may need a discussion on the
relationship between rfc2462bis and stateful address autoconfiguration
(DHCPv6).
RFC2462 currently says in Section 5.5.3 that
e) If the advertised prefix matches the prefix of an autoconfigured
address (i.e., one obtained
On Mon, 24 May 2004 23:20:39 -0700,
Christian Huitema [EMAIL PROTECTED] said:
Note that it is possible that there is no router on the link in this
sense but is a node that has the ability to forward packets. In
this case, hosts must be manually configured about the forwarding
node's
On Tue, 25 May 2004 13:14:07 -0400,
Keith Moore [EMAIL PROTECTED] said:
I am still of the belief that limiting the routing prefix to 64 bits is a
shortsighted design choice that will limit the lifetime and applicability
of IPv6. Anything we can do to discourage the notion that an
All,
Thanks for the feedback on this subject so far.
I think we are now approaching a consensus, so here is a summary of
resolution.
- keep the M/O flags
- clearly specify the protocols for the flags: RFC3315 for M and
RFC3736 for O
- clarify (change) the meaning of the M/O flags; they are
On Thu, 20 May 2004 22:14:54 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
Jinmei, I believe your proposed new text at the bottom is correct.
2462bis should not open the door to conflict in future link-layer
specs.
Okay, but after re-reading the proposed new text, I then changed my
mind a
On Mon, 24 May 2004 14:15:19 +0200,
Christian Strauf (JOIN) [EMAIL PROTECTED] said:
11. revise Section 5.5.2 as follows:
Even if a link has no routers, stateful autoconfiguration to obtain
addresses and other configuration information may still be
available, and hosts may want to use the
On Fri, 21 May 2004 23:08:24 -0400,
Bound, Jim [EMAIL PROTECTED] said:
Your wording works for me well. Good suggestion too.
Thanks, glad to hear that. But please let me check one thing: do you
have any preference between the solutions? That is,
1. remove stateful from the definition of
One more question about the prefix (and IFID) length.
Since the IFID length is defined in the link specific document (which
must be consistent with addr-arch, based on discussions so far) and
the prefix length is 128 - IFID_length by definition, the appropriate
prefix length must implicitly given
On Fri, 21 May 2004 10:01:55 +0100,
Tim Chown [EMAIL PROTECTED] said:
What do others think? Is there any other opinions?
It depends where the state is :)
Of course, but the important point is to avoid the possible confusion
that comes from the following facts:
- RFC2462 calls the
On Wed, 19 May 2004 12:16:27 +0200,
Brian E Carpenter [EMAIL PROTECTED] said:
Jinmei, I believe your proposed new text at the bottom is correct.
2462bis should not open the door to conflict in future link-layer
specs.
Okay, but after re-reading the proposed new text, I then changed my
mind
On Tue, 18 May 2004 17:46:15 +0200,
Brian E Carpenter [EMAIL PROTECTED] said:
In this message, I pointed out that there might be possible conflict
between the IPv6 address architecture and link specific documents
(e.g. IPv6 over ethernet), and asked how we can clarify the point.
On Tue, 18 May 2004 20:16:15 -0400,
Ralph Droms [EMAIL PROTECTED] said:
I share your concern about mandating the implementation of a possibly
extraneous state variable. Perhaps replacing your suggested text:
On receipt of a valid Router Advertisement (as defined in
On Mon, 17 May 2004 15:04:17 -0400,
Ralph Droms [EMAIL PROTECTED] said:
3. (optionally) make a separate document (standard or BCP) on how to
interact the protocols with these flags
Can you give some examples of what conditions or interactions might be
included in such a document?
[Note: if you've forgotten the discussion, please first refer to the
following URL (and its followups if necessary):
https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01797.html ]
In this message, I pointed out that there might be possible conflict
between the IPv6 address
On Wed, 05 May 2004 13:34:40 -0700,
Fred Templin [EMAIL PROTECTED] said:
Suggested fix is to change the 4th sentence of the first paragraph
of section 7.2.4 to:
If the solicitation's IP Destination Address is a multicast address,
the node MUST include its link-layer address (if it
On Thu, 6 May 2004 16:59:20 +0100 (BST),
Girish Kamath [EMAIL PROTECTED] said:
For Neighbor Discovery messages, is it mandatory that the scope of the source
and destination address should match?
If i have just a link-local unicast address on a node A connected to another node B
Are folks happy with the following approach? I've not seen any
objections (or any agreements either), but I'm not sure if I can start
editing based on the proposal, considering the fact that this is quite
a big set of changes.
Explicit support or objections are highly appreciated. If the list
On Mon, 17 May 2004 14:34:47 -0500,
[EMAIL PROTECTED] said:
I agree that we should not try to remove already
documented features in recycling work if it is
not causing any harm.
Before making detailed discussions, I'd repeat my position to avoid
confusion. I can live with either action
Quick checks:
On Thu, 13 May 2004 11:08:04 -0400,
Soliman Hesham [EMAIL PROTECTED] said:
- what hosts should do if the M/O flags keep being cleared; e.g.,
does this mean the hosts should not invoke the protocols?
= Stateless is a MUST according to the Node requirements. Now, if an
Now I'd like to (re)start a bigger discussion about the M/O flags: how
we should describe the relationship between the M/O flags and the
related protocols.
So far, many people seem to have (somehow) agreed on what Christian
said (attached below): the M/O flags should just be hints of
availability
On Thu, 29 Apr 2004 16:40:12 -0700,
Bob Hinden [EMAIL PROTECTED] said:
This is a IPv6 working group last call for comments on advancing the
following document as an Proposed Standard:
Title : IPv6 Scoped Address Architecture
Author(s) : S. Deering, et. al.
On Tue, 11 May 2004 09:40:45 +0200,
Stig Venaas [EMAIL PROTECTED] said:
Yes, your original analysis is correct...
Seems like the protocol associated with the 'O' bit should be RFC 3736;
there is no particular advantage to using the 4 message exchange of RFC 3315
for other configuration
(changing the subject)
On Sat, 08 May 2004 23:39:20 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
I think the O flag (if we keep it!) should simply specify DHCPv6, with no
implication about the way in which DHCPv6 is used.
Stateless DHCPv6 is simply a way to use some of the messages from
On Wed, 28 Apr 2004 12:16:15 -0400,
Ralph Droms [EMAIL PROTECTED] said:
I think the O flag (if we keep it!) should simply specify DHCPv6, with no
implication about the way in which DHCPv6 is used.
Stateless DHCPv6 is simply a way to use some of the messages from the full
specification in
On Thu, 29 Apr 2004 00:29:41 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
My point in this message is that IMO we should specify the protocols
corresponding to these flags clearly and concretely, without leaving
any ambiguity (I've changed the subject accordingly.) That is, I
strongly
On Wed, 28 Apr 2004 11:11:11 -0700,
Alain Durand [EMAIL PROTECTED] said:
Hmm, this message of yours seems to have been sent just after my
latest one...so, please let me confirm your intention. Can you or
can't you live with my revised proposal (attached below)?
see proposal inline.
On Wed, 28 Apr 2004 12:16:15 -0400,
Ralph Droms [EMAIL PROTECTED] said:
I think the O flag (if we keep it!) should simply specify DHCPv6, with no
implication about the way in which DHCPv6 is used.
Stateless DHCPv6 is simply a way to use some of the messages from the full
specification in
On Thu, 29 Apr 2004 14:50:26 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
Hmm, despite the notice, people have started and explored the
specific discussion on which protocols should be specified for the M/O
flags and how we describe it...
Please recall such a discussion will become
On Thu, 29 Apr 2004 11:09:18 -0400,
Bound, Jim [EMAIL PROTECTED] said:
3315 supports both m and o. just a fact. that I know.
I'm not really sure about the intention of the above statement, but I
guess you made your opinion (fact?) for the following point.
- which protocol should be used
On Tue, 27 Apr 2004 09:13:55 -0700,
Alain Durand [EMAIL PROTECTED] said:
The facts are:
1. there is code that sets the MO bits. (router implementations)
2. there are at least two implementations that read and
act on the O
bit. These two implementations both invoke stateless DHCPv6 as
Note: I'm responding to an old message not to restart the
deprecation discussion, but to make progress on how we can clarify
the things about these flags, assuming we have agreed on keeping them.
My point in this message is that IMO we should specify the protocols
corresponding to these flags
On Wed, 28 Apr 2004 13:28:11 +0100,
Tim Chown [EMAIL PROTECTED] said:
My point in this message is that IMO we should specify the protocols
corresponding to these flags clearly and concretely, without leaving
any ambiguity (I've changed the subject accordingly.) That is, I
strongly believe
On Wed, 28 Apr 2004 15:46:02 +0300,
Markku Savela [EMAIL PROTECTED] said:
I believe DHCP for IPv6 is totally incorrect direction. It's a
leftover dinosaur from IPv4 way of thinking.
The whole DHCP6 concept should not have been designed. Instead, the
effort should have gone to extend the
On Mon, 26 Apr 2004 22:28:05 -0700,
Alain Durand [EMAIL PROTECTED] said:
My biggest question is: can we recycle rfc2462bis as DS despite fact
3?
I failed to see what is wrong with the unused feature elimination
Christian described
when moving along the standard track.
Not sure if you're
On Tue, 27 Apr 2004 04:50:00 -0400,
Soliman Hesham [EMAIL PROTECTED] said:
1. there is code that sets the MO bits. (router implementations)
2. there are at least two implementations that read and
act on the O
bit. These two implementations both invoke stateless DHCPv6 as
the action.
=
On Tue, 27 Apr 2004 06:21:24 -0400,
Brian Haberman [EMAIL PROTECTED] said:
As a I stated in an earlier message, I believe it is okay to recycle
at DS given the granularity of detail in the interoperability reports.
http://www.ietf.org/IESG/Implementations/nd-auto-implementations.txt
On Mon, 26 Apr 2004 17:28:02 -0700,
Alain Durand [EMAIL PROTECTED] said:
At this time, the chairs believe that there is code that
sets the MO bits and at least one implementation that reads and acts
on these bits.
This is certainly not enough to claim interoperability.
Moreover, this
On Fri, 23 Apr 2004 23:24:19 +0200,
Iljitsch van Beijnum [EMAIL PROTECTED] said:
Some people commented that we needed to clarify what's bad with the
M/O flags if we want to deprecate (or remove) them.
You only discuss what would break if we deprecate these flags. I have
no problems with
On Sat, 24 Apr 2004 22:08:28 -0700,
Christian Huitema [EMAIL PROTECTED] said:
Some people commented that we needed to clarify what's bad with the
M/O flags if we want to deprecate (or remove) them.
(folding a long line)
The normal IETF practice is that when a document progresses from PS
On Mon, 19 Apr 2004 10:48:07 -0700,
Alain Durand [EMAIL PROTECTED] said:
I agree with Jim, section 5.5.2 should be deleted. Let implementations
decide
what to do if there is no router.
If you decide to keep 5.5.2, you will need to add some text to analyze
the performance impact of doing
On Thu, 15 Apr 2004 20:40:14 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
As I just said in a separate message, one big question had been raised
about rfc2462bis. It was, in my understanding,
whether we need the M/O flags for the stateful protocol(s) in the
first place.
I know
On Tue, 20 Apr 2004 09:52:34 +0200,
Tarun Kr. Sharma [EMAIL PROTECTED], Tarun_KUMAR/BE/[EMAIL PROTECTED] said:
First of all sorry for asking non relevent question but somehow it belongs to
IP. So hopefully I will get a reply for this question.
You seem to ask how NATs work and complain
On Fri, 16 Apr 2004 02:10:29 -0400,
Soliman Hesham [EMAIL PROTECTED] said:
One thing we may have to care, however, is that the lack of
implementation might be a barrier of recycling the spec as a
DS, since
we'd need to show interoperable implementations.
= Good point. It would be good
On Fri, 16 Apr 2004 15:25:30 -0700,
Alain Durand [EMAIL PROTECTED] said:
The following language from RFC2462 is still in 2462bis:
5.5 Creation of Global Addresses
Global addresses are formed by appending an interface identifier to a
prefix of appropriate length. Prefixes are
On Wed, 14 Apr 2004 06:17:18 -0400,
Soliman Hesham [EMAIL PROTECTED] said:
From router point of view, global address can be get from
Configuration. So
I am still thinking, for router case do we need ND?
= Do you think hosts connected to your router
will need the information I mentioned
On Tue, 13 Apr 2004 22:53:07 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
Regarding issue 277 of rfc2462bis (Semantics of M/O flags), one
controversial issue is how clearly we should specify the stateful
address configuration protocol.
The question actually consists of the following two
On Tue, 13 Apr 2004 22:53:07 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
Regarding issue 277 of rfc2462bis (Semantics of M/O flags), one
controversial issue is how clearly we should specify the stateful
address configuration protocol.
(forgot to mention this) in this message, I
(Sorry for not responding sooner)
On Tue, 9 Mar 2004 20:10:13 -0500 (EST),
Suresh Krishnan [EMAIL PROTECTED] said:
Don't if it is concrete or not but Section 4.2.4 of RFC2026 states
Note: Standards track specifications normally must not depend on
other standards track
On Mon, 1 Mar 2004 23:59:17 -0800 (PST),
Erik Nordmark [EMAIL PROTECTED] said:
The new section looks good but I think it should require that the host
store the times when the address would become deprecated and invalid
together with the address itself in stable storage.
Without that an
No one has provided an opinion on this...if the list is still silent,
I'll leave the current text as is, as proposed below.
If anyone of you strongly want something explicit on this in
rfc2462bis, please speak up (with proposed text if possible).
Thanks,
On Thu, 18 Mar 2004 09:45:12 -0500,
Ralph Droms [EMAIL PROTECTED] said:
For the IPv6 WG - let's cut to the chase. Is there interest in expending
any more of the IETF's resources reopening a problem for which we
have rough consensus on a solution, published specifications and running
On Tue, 02 Mar 2004 06:20:48 +0100,
Francis Dupont [EMAIL PROTECTED] said:
The address selection draft authors have asked the WG to adopt
draft-chakrabarti-ipv6-addrselect-api-02.txt as a WG document. Are
there any objections to the group adopting it? As with other API
On Wed, 10 Mar 2004 16:09:49 +0100,
Mattias Pettersson [EMAIL PROTECTED] said:
I think this is not broken at all. The host should select the correct
prefix according to the source address selection rules. I tried this
scenario approximately 3 years ago on a KAME stack and it was working
On Thu, 04 Mar 2004 03:00:08 -0500,
Ralph Droms [EMAIL PROTECTED] said:
Jinmei - I mistyped and you guessed what I had intended to ask. Good catch
and thanks for the clarification.
Can anyone supply a direct reference to an explicit statement that a DS
spec cannot have a normative
On Mon, 01 Mar 2004 10:12:41 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
According to the agenda shown at
http://www.ietf.org/ietf/04mar/ipv6.txt, we will be able to have a few
more items. If this is the case, may I ask for a short slot about an
API extension to get a list of IPv6
On Wed, 3 Mar 2004 17:47:17 -0800,
Dave Thaler [EMAIL PROTECTED] said:
But the first condition seems to me a bit subjective. Under which
requirement can we decide a document must be read for a different
document?
The second condition is a bit clearer, but assuming we basically
agreed
On Thu, 04 Mar 2004 02:33:23 -0500,
Ralph Droms [EMAIL PROTECTED] said:
In the wg meeting on Tuesday, several concerns were raised regarding
this issue (and the proposed resolution). To summarize (some of)
them,
1. the resolution proposes to say the stateful protocol is DHCPv6
clearly,
On Mon, 1 Mar 2004 00:08:54 -0800 (PST),
Erik Nordmark [EMAIL PROTECTED] said:
Fair enough, but let me make a quick check: is this a direct response
to my request for a slot (positive or negative), or just a general
input on this issue itself?
Latter.
On the former; Getting the API for
On Sun, 29 Feb 2004 15:03:15 +0200,
Jari Arkko [EMAIL PROTECTED] said:
Most or maybe even all of these aspects are being worked by different
groups. For instance,
(snip)
Does this count as a comprehensive scenario you were looking
for?
I think so, thanks for the list.
In the optimistic
On Mon, 1 Mar 2004 00:12:11 -0800,
James Kempf [EMAIL PROTECTED] said:
Putting that aside, a SEND node could well *defend* the address
fe80::A for DAD/DIID purposes, but it would never actually use it.
I think that's the issue. Should a SEND or 3041 node be required to defend
LL addresses
On Mon, 01 Mar 2004 19:20:21 -0500,
Brian Haberman [EMAIL PROTECTED] said:
The chairs have decided to handle document status differently
at IETF 59. Rather than spending valuable meeting time on status,
we have created a webpage with the current status of all documents.
It is now
On Mon, 01 Mar 2004 22:34:47 +0200,
Mika Liljeberg [EMAIL PROTECTED] said:
Okay, I'm happy to reach the consensus, too.
Futile though it may be, I would like to register disagreement.
I think it is not necessarily futile, though in my understanding (I
must admit it may be biased) many
On Fri, 27 Feb 2004 18:59:25 +1100,
Nick 'Sharkey' Moore [EMAIL PROTECTED] said:
Honestly speaking, I don't see the need for making DAD compatible
with DIID in the first place. Recall that DAD is not compatible
with DIID in this sense, even with the current RFC2462.
There is not
On Sun, 29 Feb 2004 17:16:30 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
Suppose that a DIID node has an interface identifier (which is
probably derived from the hardware address) I. The DIID node first
tries DAD for fe80::I. If the node does not see a duplication, then
it will
Sorry for not responding sooner...
On Thu, 5 Feb 2004 09:43:00 -0500,
Kristine Adamson [EMAIL PROTECTED] said:
I know the IETF isn't the most appropriate place to discuss this type
of thing, but does it help to write a short informational I-D
describing the specification with some
According to the agenda shown at
http://www.ietf.org/ietf/04mar/ipv6.txt, we will be able to have a few
more items. If this is the case, may I ask for a short slot about an
API extension to get a list of IPv6 addresses (as well as other AF
addresses) on a node? This was discussed in the wg list
On Sun, 29 Feb 2004 18:24:33 -0800 (PST),
Erik Nordmark [EMAIL PROTECTED] said:
It would be good to ask (e.g. on the appsarea list - [EMAIL PROTECTED]
I think) if there are applications that need other configuration information
than the list of interfaces/ifindicies (which we already have)
On Fri, 27 Feb 2004 16:15:30 +0900,
S. Daniel Park [EMAIL PROTECTED] said:
And even with single id and new prefix this is not good: on
RA with a new global prefix, every node on the link is going to do
DAD based on its ID and new prefix. And, as far as I know,
there is no delay
I've been thinking about this issue for a while. Currently, I'm not
sure if we need to do something in rfc2462bis for this issue.
I originally thought RFC2462 had some sort of assumption that an
interface identifier is 64 bits long at least for some cases.
Looking at RFC2462 again, however, I've
(note: this is a long message.)
One major open issue of rfc2462bis is semantics of the M/O bit,
what stateful configuration means, etc.
Ralph Droms raised a set of questions in March 2003:
a. the text needs to be updated to use RFC 2119 keywords
b. which keywords?
c. what is the stateful
On Mon, 23 Feb 2004 22:21:49 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
Since we have a discussion about optimistic DAD, this is probably a
good chance to start a related discussion for rfc2462bis.
(...snip...)
Having considered these points, possible resolutions *for rfc2462bis*
that
On Thu, 26 Feb 2004 11:46:58 +0200,
Markku Savela [EMAIL PROTECTED] said:
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= [EMAIL PROTECTED]
So, I'd now like to propose a concrete change. The simplest way to
implement the option would be to remove the second exception shown in
On Fri, 27 Feb 2004 13:44:08 +1100,
Nick 'Sharkey' Moore [EMAIL PROTECTED] said:
NB: Is there a plan for 3041bis? It's rather bound up with
DIID too.
A quick response. I guess you are talking about the following part of
RFC3041:
Note: because multiple temporary addresses are
On Fri, 27 Feb 2004 07:09:02 +1100,
Nick 'Sharkey' Moore [EMAIL PROTECTED] said:
Yes, DIID probably (or something similar). I believe that simplest
solution is that a specific ID value can be allowed only for single
node on the link. Any use of same ID part with any prefix by another
node
On Thu, 26 Feb 2004 23:15:08 +1100,
Nick 'Sharkey' Moore [EMAIL PROTECTED] said:
Sorry, I don't understand the concern...by which scenario might the
latter not be defending the link-local address? (perhaps I don't
understand what you meant by defend...)
Sorry, that's me being obscure:
On Thu, 26 Feb 2004 20:54:32 +1100,
Nick 'Sharkey' Moore [EMAIL PROTECTED] said:
If yes, is the requirement of DAD **MUST** take place acceptable? I
believe this is acceptable in essence, but I'd like to know this does
not cause a severe compatibility issue with existing implementations
Catching up an old topic...
On Tue, 10 Feb 2004 07:26:05 -0500,
Soliman Hesham [EMAIL PROTECTED] said:
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
1 - 100 of 135 matches
Mail list logo
