In article <[EMAIL PROTECTED]> (at Mon, 01 Mar 2004 17:27:22 +0900 (JST)), YOSHIFUJI
(BHideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> says:
(B
(B> 2. The description for "ifa_flags" is rather bogus.
(B>For L3 addresses, it seems to return IFA_xxx (or IN6_IFA_xxx?) flags,
(B>instead
On Tue, 2 Mar 2004, Myung-Ki Shin wrote:
> > SSM range is FF3X::/32. This draft invades in that territory.
>
>No, as mentioned before,
>SSM format is FF3X::/96 in section 7 of RFC 3306.
>Thus, it is distinguishable.
Sorry, SSM WG does not agree with this interpretation.
>So, whi
Please see comments below :
Pekka Savola wrote:
> On Mon, 1 Mar 2004, Dave Thaler wrote:
> > Pekka Savola writes:
> > > On Tue, 2 Mar 2004, Jung-Soo Park wrote:
> > > > I revised my draft (-04) according to comments of ML.
> > > > My revised draft is available as follows:
> > > > http://www.ipv6.
> 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 bia
On Mon, 1 Mar 2004, Dave Thaler wrote:
> Pekka Savola writes:
> > On Tue, 2 Mar 2004, Jung-Soo Park wrote:
> > > I revised my draft (-04) according to comments of ML.
> > > My revised draft is available as follows:
> > > http://www.ipv6.or.kr/eng/draft-ietf-ipv6-link-scoped-mcast-04.txt
> >
> > I
In your previous mail you wrote:
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
documents, this would be Informational in nature.
Pekka Savola writes:
> On Tue, 2 Mar 2004, Jung-Soo Park wrote:
> > I revised my draft (-04) according to comments of ML.
> > My revised draft is available as follows:
> > http://www.ipv6.or.kr/eng/draft-ietf-ipv6-link-scoped-mcast-04.txt
>
> I don't think this addresses my concerns. This does no
All,
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
documents, this would be Informational in nature.
Regards,
Brian & Bob
-
On Tue, 2 Mar 2004, Jung-Soo Park wrote:
> I revised my draft (-04) according to comments of ML.
> My revised draft is available as follows:
> http://www.ipv6.or.kr/eng/draft-ietf-ipv6-link-scoped-mcast-04.txt
I don't think this addresses my concerns. This does not work with
source-specific mult
Hi Brian and folks
I revised my draft (-04) according to comments of ML.
My revised draft is available as follows:
http://www.ipv6.or.kr/eng/draft-ietf-ipv6-link-scoped-mcast-04.txt
In my previous draft,
if scope <=2, my proposal only has to use(MUST).
According to Erik's comment, "MUST" is update
Hi Brian,
For the IPv6 Nodes Requirement,
Revised ID Needed
draft-ietf-ipv6-node-requirements-08.txt (To be discussed in WG session)
The document has been revised, I just want a sanity check on a couple of things,
but I think the document should be marked "This version addresses
> On Mon, 01 Mar 2004 19:58:42 -0500,
> Brian Haberman <[EMAIL PROTECTED]> said:
> I was planning on doing a short (1 week) WG Last Call to allow
> commenters a chance to review the changes.
Fine, thanks.
JINMEI, Tatuya
I was planning on doing a short (1 week) WG Last Call to allow
commenters a chance to review the changes.
Regards,
Brian
JINMEI wrote:
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. Rath
Pekka,
Pekka Savola wrote:
On Mon, 1 Mar 2004, Brian Haberman wrote:
http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentStatus.html
What about the other work we should be doing, but isn't done yet (PPP
updates, "link-scoped multicast", point-to-point link support,
rfc3041bis, etc.)
> 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.
On Mon, 1 Mar 2004, Brian Haberman wrote:
> http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentStatus.html
What about the other work we should be doing, but isn't done yet (PPP
updates, "link-scoped multicast", point-to-point link support,
rfc3041bis, etc.) ?
One comment:
RFC Editor's
All,
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 available at:
http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentStatus.h
Introduction, Agenda Bashing, Document Status 05
Charter Update , Hinden 10
Node Requirements, Loughney 10
2461bis, Soliman15
2462bis, Tatuya15
ICMP Updates, Gupta/Hinden
Thus spake "Jyrki Soini" <[EMAIL PROTECTED]>
> There is discussion and motivation why ICMPv6 error messages in general
> case MUST NOT be send in response to multicast packets. In contrast
> ICMP Echo Reply message has the following text:
>
> "An Echo Reply SHOULD be sent in response to an Echo R
On Mon, 1 Mar 2004, Jyrki Soini wrote:
> "An Echo Reply [SHOULD NOT| MAY] be sent in response to an Echo
> Request message
> sent to an IPv6 multicast or anycast address. If this potentially
> dangerous reply
> is sent, the source address of the reply MUST be a unicast address
> be
There is discussion and motivation why ICMPv6 error messages in general
case MUST NOT be send in response to
multicast packets. In contrast ICMP Echo Reply message has the following
text:
"An Echo Reply SHOULD be sent in response to an Echo Request message
sent to an IPv6 multicast or anycast
On Mon, 2004-03-01 at 17:25, JINMEI Tatuya / çæéå wrote:
> Okay, I'm happy to reach the consensus, too.
Futile though it may be, I would like to register disagreement.
If the intention truly was to simplify the specification, we would be
going to pure DIID. As it is, removing mention of DIID seem
> On Mon, 1 Mar 2004 22:13:26 +1100,
> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said:
>> [...] In this particular case, "A" is a
>> CGA identifier, so it cannot equal to a normal EUI-64 identifier.
> I had not thought of this! So
> it is not a problem at all.
> In that case I'm entir
> 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.
> 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; G
On 2004-03-01, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
> I don't see the need for any change on this in rfc2462bis.
Okay, no worries, I'm happy too:
I had assumed the DIID behaviour
was widespread.
>[...] In this particular case, "A" is a
> CGA identifier, so it cannot equal to a normal E
I agree.
jak
- Original Message -
From: )>
To: "James Kempf" <[EMAIL PROTECTED]>
Cc: "Pekka Nikander" <[EMAIL PROTECTED]>; "Nick 'Sharkey' Moore"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, March 01, 2004 1:28 AM
Subject: Re: SEND/DIID interope
To summarize the points, I'd propose to do nothing on this in
rfc2462bis because:
- the actual odds of the problem in the real world should be very low,
even in the current status.
- if we take the proposed change in rfc2462bis, the odds will be
getting lower and lower.
- if we add something fo
> 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 de
Hello.
(B
(BIn article <[EMAIL PROTECTED]> (at Mon, 01 Mar 2004 16:54:25 +0900), JINMEI Tatuya /
(B[EMAIL PROTECTED]@C#:H(B <[EMAIL PROTECTED]> says:
(B
(B> FYI: currently getifaddrs(3) provides the following information:
(B>
(B> char *ifa_name; /* Interface n
> 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 that use suffixes configured for their global unicast addresses
even thou
> 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 the list of addresses documented seems
quite useful so I think it makes sense spen
32 matches
Mail list logo
