Subject: Re: narten's review of 2461bis

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 01 Dec 2006 17:16:45 +0900

>>>>> On Thu, 30 Nov 2006 23:09:10 +1100, 
>>>>> "Hesham Soliman" <[email-masked]> said:

>> Substantive:
>> 
>> Some of other standards track documents have extended ND. Some of
>> these extensions should be mentioned in this document, as some of them
>> seem to actually update this document.

> => We discussed these extensions when the bis was prepared, I think we
> discussed all of them. At the time the WG didn't agree with even including
> the H bit, the R bit, the changes in inter-RA timers ...etc Adding any of
> those issues to the current draft was rejected by a large margin. I
> personally thought it would make sense to include things like the H and R
> bits in the RA, but most people didn't agree at the time. This was around
> the Seoul IETF if memory serves me right. 

The decision is recorded at the issue list page for 2461bis.  Examples
are:
https://rt.psg.com/Ticket/Display.html?id=255
https://rt.psg.com/Ticket/Display.html?id=259
(user/password=ietf/ietf for read only access)

As (some) others pointed out, I'd also like to not incorporate this
change to this document at this stage.  One possible compromise is to
add an appendix that provides a short list of recent updates (RFC
numbers) to the ND protocol and note that 2461bis does not intend to
disapprove the changes but the updates are not incorporated due to
maturity level and compatibility issues.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 01 Dec 2006 17:17:11 +0900

>> >    The set of addresses assigned to an interface may change over time.
>> >    New addresses might be added and old addresses might be removed
>> >    [ADDRCONF]. In such cases the node MUST join and leave the
>> >    solicited-node multicast address corresponding to the new and old
>> >    addresses, respectively. Joining the solicited-node multicast
>> address
>> >    SHOULD be done using the Multicast Listener Discovery [MLD] or
>> >    [MLDv2] protocols. Note that multiple unicast addresses may map into
>> >    the same solicited-node multicast address; a node MUST NOT leave the
>> >    solicited-node multicast group until all assigned addresses
>> >    corresponding to that multicast address have been removed.
>> 
>> Hmm. should we point to MLD v1 at all? And doesn't the SHOULD make
>> this  a normative reference? 

> => Yes to both questions I think. If we didn't point to MLDv1 then the
> change woulod not be backward compatible. I.e. using MLDv2 only would break
> old implementations. As for the second question, I agree that it makes MLDv2
> normative but I was hoping the "or" would get us out of this dilemma.

I suspect the main issue is that [MLD] (RFC2710) and MLDv2 (RFC3810)
are both in the PS status and normative reference(s) to these would
cause a downref issue.  In this sense "or" doesn't help.

Meanwhile.  If I remember correctly, this sentence was added due to a
claim from someone who argued it is not clear that joining a multicast
group normally involves MLD (whether it's v1 or v2) operations.  To me
it's too trivial and mentioning it in this context is superfluous.
It's here probably because including it was a consensus at that time,
but now that it's going to be a blocking issue, I'd like to ask for a
reconsider.  Do we really need to mention this "trivial (to me)" thing
here?

Even if we do, I doubt the reference should be normative.  According
to RFC3967, a rough definition of a normative reference is as follows:

   Broadly speaking, a normative reference specifies a document that
   must be read to fully understand or implement the subject matter in
   the new RFC, or whose contents are effectively part of the new RFC,
   as its omission would leave the new RFC incompletely specified.

If I'm allowed to talk about a particular implementation, I'd be able
to implement the relevant part of RFC2461 (or 2461bis) without reading
[MLD] or [MLDv2] on the KAME/BSD stack.  In fact, this implementation
provides a routine named in6_joingroup(), and I'd simply call this
function from a routine that configures a new address.  This is a
straightforward implementation of "the node MUST join (and leave) the
solicited-node multicast address", and I don't care whether
in6_joingroup() internally performs MLDv1 or v2 operation (it does
actually).

I'm not arguing this can be generalized for other implementors, but at
the same time I believe this is essentially applicable to many other
implementations because joining/leaving a multicast group is a very
common operation.

So, my suggestion to this issue is (in the preferred order):

1. remove the sentence mentioning MLD, or
2. change the sentence to
   Joining the solicited-node multicast address is done using the
   Multicast Listener Discovery [MLD] or [MLDv2] protocols.
(and leave [MLD] and [MLDv2] informative)

Note: there is another occurrence of references to [MLD] and [MLDv2]
in Section 7.2.8, which should also be updated.

>     IPv6 node reqirements provides more
>> guidance on when to use MLD vs. MLDv2. should we include similar text?
>> Is there some other standards track document to refer to? Or should we
>> just provide a pointer to node requirements, even though it is only an
>> informational RFC?

> => All good questions, does anyone have a suggestion here? I can't think of
> one yet. I'm also not sure if we need to give recommendations for MLDv1 Vs
> v2 if there is another document that does that in a generic manner (i.e. not
> specific to this doc). 

If we choose option 1 above, this problem will automagically go away:-)

If we still need to mention the MLD protocols, I don't think we need
to discuss the preference between MLDv1 and MLDv2 in this context.
One possible wording trick is to change the above option to further:

   Joining the solicited-node multicast address is done using a
   Multicast Listener Discovery protocol such as [MLDv2].

					JINMEI, Tatuya

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 1 Dec 2006 22:26:22 +1100

> cause a downref issue.  In this sense "or" doesn't help.

=> Ok, but your argument below is predicated on that as an implementer you
don't need to read or understand MLD to implement ND. So if this is the case
then I think you agree that neither one is normative. If they are in fact
normative then removing the sentence doesn't help, it would only hide the
fact that they are normative. 

 > group normally involves MLD (whether it's v1 or v2) 
 > operations.  

=> Yes that's how I remember it too. 

   To me
 > reconsider.  

=> It's only a blocking issue if we consider MLD normative. As I said above,
if it's normative then removing the sentence is not the right thing to do.
OTOH, if it's not normative then there is no problem.

 >    must be read to fully understand or implement the subject 

=> Hmm.

 > in6_joingroup() internally performs MLDv1 or v2 operation (it does

=> Hmm, I can make the same argument about IPsec in MIPv6, but it is in fact
normative. You basically assumed the existence of MLD, but if you were
starting from scratch you couldn't implement ND without implementing MLD. 

 > (and leave [MLD] and [MLDv2] informative)

=> I prefer to keep the sentence, I think the normative issue should be
handled regardless of the presence of the sentence.

 > in Section 7.2.8, which should also be updated.

=> Ok.

 >    Multicast Listener Discovery protocol such as [MLDv2].

=> This is fine with me. 

Hesham

---

From: Thomas Narten <[email-masked]>
Date: Fri, 01 Dec 2006 08:42:50 -0500

> But, I was "shouted" down, so I don't oppose it either.

Perhaps, but this also makes it sound like there were now compelling
reasons to oppose the change.

Fact is, the IPv6 WG made the decision a long time ago (10+ years?)
that even if snooping bridges are an abomination (and many people
think they are), they were to be supported anyway. This is just
carrying over from IPv4 a feature that was felt to be needed. Way too
late to roll back the clock now.

Thomas

---

From: Markku Savela <[email-masked]>
Date: Fri, 1 Dec 2006 15:33:59 +0200

>  > group normally involves MLD (whether it's v1 or v2) 

Perhaps it was me? I opposed the need to use MLD (of any kind) for
*LINK LOCAL SCOPED* multicast groups. My rationales were

- MLD is for communicating with Multicast Router. Multicast router has
  nothing to do with link local multicast.

- sending MLD for link local multicast generates extra packets.

I was countered that these MLD's were needed for some "intelligent"
bridges to get neighbor discovery work. My view was that such layer 2
sniffing devices should not generate requirements to IP layer, and all
information for them would have been available from the ND messages
anyway (now the join to solicited address group goes back-to-back with
duplicate address test -- same info in both packets essentially).

-- 
Markku Savela

---

From: Brian Haberman <[email-masked]>
Date: Fri, 01 Dec 2006 09:32:16 -0500

Erik Nordmark wrote:
> Thomas Narten wrote:
> 
>>>         CurHopLimit    The default hop limit to be used when sending
>>>                        (unicast) IP packets.
>>
>> why only unicast? seems like this should also apply to multicast.  Are
>> the default values for multicast different  than unicast? (I think the
>> answer is yes for IPv4, but I'm not sure that applies to IPv6. IPv6
>> multicast addresses have explicit scoping, whereas IPv4 multicast used
>> the TTL for that...)
> 
> I don't know how much we've discussed it, but I think IPv6 needs to have
> a default hoplimit for multicast of 1, just like IPv4. Applications can
> use IPV6_MULTICAST_HOPLIMIT etc to set a different value.

Will people have an issue with a default Hop Limit of 1, when some
protocols (e.g. ND) use HL=255?  A default of 1 does not make sense to
me for multicast scopes above link-local.

Regards,
Brian

---

From: Markku Savela <[email-masked]>
Date: Fri, 1 Dec 2006 15:33:59 +0200

-- 
Markku Savela

---

From: Brian Haberman <[email-masked]>
Date: Fri, 01 Dec 2006 09:32:16 -0500

Regards,
Brian

---

From: Tim Chown <[email-masked]>
Date: Fri, 1 Dec 2006 15:13:00 +0000

> But, I was "shouted" down, so I don't oppose it either.

I certainly have some sympthy with that view, but also as a site with
multiple IPv6 multicast video sources we do appreciate the functionality
that MLD snooping offers us.

We'd also be quite happy to see other IPv6-specific snooping, e.g. adding
RA snooping could be quite useful.

Not trying to reignite a debate, just saying it's useful operationally.

-- 
Tim

---

From: Ralph Droms <[email-masked]>
Date: Fri, 01 Dec 2006 10:26:32 -0500

Just as a general intuition, I'm concerned that the IPv6 suite is becoming
less careful over time about the use of "soft state" inferred from snooping
various protocol interactions.  IMHO, inferring soft state is OK, as long as
that state is an optimization and not a requirement for system operation;
put another way, inferring state that must be reconstructed after loss of
that state entangles protocols in unhealthy ways...

For example, how does a layer 2 device that requires multicast information
gleaned from MLD transactions reconstruct that state?  I'm sure it's
possible; is that entanglement with MLD desirable?

- Ralph

---

From: Stig Venaas <[email-masked]>
Date: Fri, 01 Dec 2006 17:01:11 +0100

> gleaned from MLD transactions reconstruct that state?  I'm sure it's

There are regular MLD reports and queries. It would have to wait for the
next general query and check the reports.

> possible; is that entanglement with MLD desirable?

Unfortunately, the current de-facto standard to limit flooding of
multicast in a LAN is MLD snooping. If some hosts were to not send
MLD reports for say the solicited address group, there is a danger
that they won't receive the multicast packets from the switch.

There are other protocols around that could have been used instead
of snooping, but there are various issues/reasons they haven't been
deployed or why snooping unfortunately is preferred.

Even if some particular protocol was used, the host would still need
to do some membership signalling on the wire...

Some switches may always flood certain groups though. E.g. having all
hosts join different solicited address groups creates a lot of state
in the switch, and for such low-rate groups it might be just as well
to always flood them.

Anyway, to be on the safe side, I think hosts should always send MLD
reports for link-local groups.

Stig