Subject: Re: Duplicate Address Detection on a link-local address

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 02 Jul 2001 16:05:00 +0900

>>>>> On Fri, 29 Jun 2001 15:31:06 -0400, 
>>>>> "Roy Brabson" <[email-masked]> said:

> I've got a question on Duplicate Address Detection for link-local
> addresses.  DAD states that a node must join the solicited-node
> multicast group for the tentative address before beginning DAD.
> Multicast Listener Discovery states that as part of joining a link-scope
> multicast groups, other than the all-nodes group, a MLD Report message
> must be sent.  MLD also states that the source IP address in the MLD
> message must be a link-local address.

> So, what should be put in the source address for the MLD Report when the
> a link-local address is being assigned and no other addresses exist for
> the link?

This has already been discussed, and the consensus was this:

> There are some other alternatives which might make sense if bridges are
> keying off MLD Reports to determine whether to forward multicast
> packets:
> - When assigning a tentative link-local address and no other address
>   exists for the router, send an MLD Report with the source address set
>   to the unspecified address.  This is currently not allowed by MLD and
>   might result in the packet failing verification by a bridge/router and
>   therefore being discarded.

See also the following discussion:
http://www.wcug.wwu.edu/lists/ipng/200007/msg00193.html

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Jul 2001 11:05:37 +0300 (EEST)

> http://www.wcug.wwu.edu/lists/ipng/200007/msg00193.html

Speaking of which, I'm not sure whether there exists IETF practise for
this..

Should there be notes kept on upcoming changes/caveats of different RFC's
published by ipngwg?

I mean, issues like these are pretty difficult to find in the mailing list
archives if you weren't there (and even if you were, you might not
remember them).

Having these written down somewhere per RFC would make sure that they'll
be checked when the RFC is being revised, and read by those interested in
the issues.

A draft version of the "updated" RFC if you may; of if not that, links to
relevant discussions on the list.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 02 Jul 2001 19:16:22 +0900

>Should there be notes kept on upcoming changes/caveats of different RFC's

	maybe this is time to compile "host requirement".  Hi Marc ;-)

itojun

---

From: Matt Crawford <[email-masked]>
Date: Mon, 02 Jul 2001 09:29:42 -0500

> 	maybe this is time to compile "host requirement".  Hi Marc ;-)

We have resisted that on several occasions before,
but maybe now it IS time.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Jul 2001 17:49:30 +0300 (EEST)

> 	maybe this is time to compile "host requirement".  Hi Marc ;-)

Can "problems" like these be addresses by writing a completely new RFC?

Sure, if it were decided to never advance current RFC's, then writing new
ones would help. ;-)

But would it make sense to record some bits against current RFC's, so that
nothing gets lost/forgotten when revising them?  This way the information
would be available in "raw" (I'd say draft, but that might have strong
connotations) form?

For example, once upon a time I was reading through KAME nd6_rtr.c, and
saw:

#if 0   /* RFC 2462 5.5.3 (e) */
 [...]
#else   /* update from Jim Bound, (ipng 6712) */
 [...]
#endif

Now try to figure out _which_ of the dozens of possible mail archivers
that could be on.. ;-)

Is this against IETF methodology?  Would doing this mean that new
"revisional" I-D's would have to be started on the subject?

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 02 Jul 2001 12:02:28 -0400

>         maybe this is time to compile "host requirement".  Hi Marc ;-)

I know. Been working on that sloowly: did a lot of reading and note 
writing: this is a lot of work: so many documents: not only in the ipngwg, 
but also ngtrans, and other wg (mobileip, dhcp, ...)!  A colleague started 
a parser to parse every document to find all the occurences of 
MUST/MAY/SHOULD and make a listing of it: was useful but a lot of noise to 
clear.

Maybe I should wrap what I did up to now and then send it to you, so you 
will send me updates and this process will give me more pressure to finish 
the work... ;-)))

Marc.