Subject: Comment on RFCs 2461bis and 2462bis

From: Christian Vogt <[email-masked]>
Date: Fri, 27 May 2005 19:20:51 +0200

Hi everybody,

one comment concerning RFCs 2461bis and 2462bis.  The documents define 
that a node must delay...

- its initial Router Solicitation after interface (re-) initialization 
(D1) [RFC 2461bis]
- joining the solicited-nodes multicast address after interface (re-) 
initialization (D2) [RFC 2462bis]
- joining the solicited-nodes multicast address before starting DAD 
triggered on a multicast RA (D3) [RFC 2462bis]

RFC 2461bis explicitly mentions, in section 6.3.7, that the delay for 
Router Solicitations (D1) can be omitted by mobile nodes.  This helps to 
detect movement more quickly.

However, RFC 2462bis has no equivalent rule with respect to the delay 
for sending a MLD Report (D2, D3).  So, when it comes to configuring a 
new address through DAD, nodes must still delay joining the 
solicited-nodes multicast address, which in turn delays DAD.

As a consequence, mobile nodes can get a RA quickly by avoiding (D1), 
but they are still stuck with (D2) or (D3).  This prevents rapid 
re-attachment after a handover.

Besides, RFC 2461bis's relaxation of (D1) for mobile nodes has no 
effect---at least not to the extent it should---if you still have (D2) 
and (D3).

To make this story short:  Even at the risk of suggesting something that 
has been discussed on the IPv6 mailing list before, I propose to remove 
delays (D2) and (D3) in RFC 2462bis for mobile nodes.  I know there is 
an issue with contention when a multicast RA triggers multiple MLD 
Reports.  The question is how likely that is, and how much more often 
delays (D2) and (D3) would be disruptive to mobile nodes.

Bye for now,

- Christian

PS: One side note about recovery:  Nodes will recover from MLD Report 
collisions.  But if an MLD Report fails, and two nodes simultaneously 
attempt to configure the same IPv6 address at that time, this 
duplication won't be detected.  And nodes would not recover either.

PPS:  As an alternative to relaxing (D2) and (D3), one may think about a 
relaxation on the requirement to join the solicited-nodes multicast 
address *prior* to DAD.  After all, DAD does work if the initiator has 
not joined the group, because any NAs will be sent to the all-nodes 
multicast address.  The only issue is a situation in which two nodes 
attempt to configure the same address at the same time.  The question is 
how likely that is...

PPPS:  As far as I see, the ODAD draft does not mention or tackle the 
delay for MLD Reports either.  Maybe that should be changed, too.  Nick?

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 28 May 2005 15:53:51 +0900

>>>>> On Fri, 27 May 2005 19:20:51 +0200, 
>>>>> Christian Vogt <[email-masked]> said:

> that a node must delay...

I'd like to begin with a general note...

> delays (D2) and (D3) would be disruptive to mobile nodes.

Yes, we've already discussed this sort of thing, probably several
times.  The basic consensus was we would not introduce any changes
that can affect non-mobile nodes just for helping mobile nodes, at
least within the scope of 2461bis/2462bis, due to the "conservative"
nature of the recycling process.  See, for example, discussions at
58th IETF at: http://www.ietf.org/proceedings/03nov/137.htm

In this sense, we'd not justify a logic like "disruption without
random delay should be very rare and eliminating the delay would help
mobile nodes very much.  So let's introduce the optimization".  What
we need to justify the change is a proof that the change never affects
existing (non mobile in this case) implementations, not a doubt about
the probability of disruption.

In fact, the change about "D1" in rfc2461bis was introduced with very
careful wording for not disrupting existing implementations.  Also, we
should note that other "radical" changes like changing RA frequency
(to every 50ms) or removing random delay before sending RAs were
rejected, mainly based on the "conservative" principle.

Note that this policy is limited to 2461bis/2462bis.  We can still
discuss, implement, or even standardize any new ideas *as a separate
work item*.  And, indeed, the mobile IPv6 specification introduces a
new RA frequency, and optimistic DAD is now going to become a PS.
Someday, when we have enough operational experience on the new ideas,
those may be incorporated into the base specification.  But clearly
it's not now.

I hope this explanation helps avoid having the "101th" discussion
about a new change proposal into 246[12]bis based on the "but isn't it
unlikely?" type of logic.

Now going to specific points...

> triggered on a multicast RA (D3) [RFC 2462bis]

Hmm..., regarding D2, it seems we can apply the same approach as D1 in
2461bis.

Regarding D3, I'm not sure if we can make it for 2462bis, since this
event is not (necessarily) triggered by moving a link, and it may be
difficult to find a prudent condition like the one described in
2461bis for D1.  Recall that our first priority in 2462bis is to avoid
disruption for existing implementations, not to provide mobile nodes
an easy way out.

Besides, even if we remove D3, the mobile node will still face a delay
in this case, because the responding router will impose a random delay
before sending an RA.

So, I'm negative about removing D3 from rfc2462bis.  Is this decision
okay for you?

Assuming the answer is yes for now, do we still want to remove D2?  As
you pointed out, just removing D2 may not necessarily help mobile
nodes, so the change would still be incomplete.  Considering the
current status of the document (already passed an IESG last call, and
now waiting for IESG approval), I'm personally reluctant to introduce
the change at this stage.  But if many others also want the change
(and no one objects to that), I'll try to revise the draft once again.

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

---

From: Christian Vogt <[email-masked]>
Date: Sun, 29 May 2005 19:36:34 +0200

Hi Jinmei.

> times.

I was assuming this, but probably browsed the list too little
diligently.  I'm sorry; my mistake.

>> - its initial Router Solicitation after interface (re-) 
>> initialization (D1) [RFC 2461bis] - joining the solicited-nodes 
>> multicast address after interface (re-) initialization (D2) [RFC 
>> 2462bis] - joining the solicited-nodes multicast address before 
>> starting DAD triggered on a multicast RA (D3) [RFC 2462bis]
> 
> Hmm..., regarding D2, it seems we can apply the same approach as D1 
> in 2461bis.

As far as I see, we should either do that, or RFC 2461bis' relaxation on
D1 for MNs would be useless in most situations.

> 2461bis for D1.  Recall that our first priority in 2462bis is to 
> avoid disruption for existing implementations, not to provide mobile 
> nodes an easy way out.
> 
> Besides, even if we remove D3, the mobile node will still face a 
> delay in this case, because the responding router will impose a 
> random delay before sending an RA.

Well, here is the scenario I am thinking of:  A MN uses unsolicited
RAs---neither RSs, nor link-layer triggers---to detect IP-attachment
changes.  Assuming that routers send their RAs every 50ms on average,
which is what RFC 3775 allows them to do, this movement-detection
strategy works better than sending RSs.  The reason is the random delay
for solicited RAs, as you say.  Even if the MN would use L2 triggers, it
would still have to send an RS and await the random RA-delay in order to
find out the new prefix(es).

So, RFC 3775's frequent (unsolicited) RAs can be leveraged for movement
detection quite nicely.  But when it comes to configuring the new
address, the MN ends up having to wait for D2 or D3 to send the MLD
Report.  In other words, eliminating D1 turns out to be useless as long
as D2 and D3 are still there.

I guess my point is that, conceptually, RFCs 246[12]bis impose ONE
SINGLE delay for the first transmitted message whenever there is a
danger for contention.  If an RS is the first transmitted message, the
RS needs to wait (D1).  If a MLD Report is the first, it will be delayed
(D2).  Same with the NS for DAD after a multicast RA (D3).  Once the MN
has awaited one of these delays, it does no longer need to await the others.

Contention may happen due to simultaneous boot-up of multiple hosts, or
due to synchronized DAD after a multicast RA.  Unfortunately, the
original wording paraphrasing these conditions encompasses the condition
of a handover, which is unintentional because handovers usually don't
cause contention.

The goal with RFCs 246[12]bis seems to be a relaxation for the handover
condition.  But this goal has yet to be met:  If one removes D1 for MNs,
namely D1, that doesn't help unless one either removes D2 and D3 as
well, or has a particular approach in mind with which a MN could get
away with only one or two delays (which, or each of which, would have to
be eliminated then).

I know the intent is to make RFCs 246[12]bis as conservative as
possible, and to move any optimization to separate documents.  In fact,
I do like that idea.  But as things stand, either would RFCs 246[12]bis
prevent certain optimizations like frequent RAs a la RFC 3775, or such
optimizations would have to explicitly revoke delays defined in RFC
246[12]bis.  However, if RFCs 246[12]bis had the kind of relaxation for
D2 and D3 as it already has for D1, then optimizations could just refer
to this relaxation, and there would be no conflict.

The challenge would therefore be to paraphrase the condition in which
the relaxation could be applied, i.e., a wording that describes a
handover, but does not include any other condition.

Having said the things above, I hope I could strengthen the case for
relaxing both D2 and D3 for MNs---similar to how it's already done for D1.

> So, I'm negative about removing D3 from rfc2462bis.  Is this decision

Well, see above... ;)

Let's put it this way:  I would like to see the documents handle both D2
and D3 in the way they do with D1.  But that's just my personal opinion...

> nodes, so the change would still be incomplete.

Right.

> Considering the current status of the document (already passed an 
> IESG last call, and now waiting for IESG approval), I'm personally 
> reluctant to introduce the change at this stage.  But if many others 
> also want the change (and no one objects to that), I'll try to revise
>  the draft once again.

Yes, sorry for raising this so late.

And thanks for your detailed response!

Regards to all,

- Christian

JINMEI Tatuya wrote:
>>>>>> On Fri, 27 May 2005 19:20:51 +0200, Christian Vogt
>>>>>> <[email-masked]> said:
> 
> 
>> one comment concerning RFCs 2461bis and 2462bis.  The documents
>> define that a node must delay...
> 
> 
>> To make this story short:  Even at the risk of suggesting something
>> that has been discussed on the IPv6 mailing list before, I propose
>> to remove delays (D2) and (D3) in RFC 2462bis for mobile nodes.  I
>> know there is an issue with contention when a multicast RA triggers
>> multiple MLD Reports.  The question is how likely that is, and how
>> much more often delays (D2) and (D3) would be disruptive to mobile
>> nodes.
> 
> 
>  we need to justify the change is a proof that the change never
> affects existing (non mobile in this case) implementations, not a
> doubt about the probability of disruption.
> 
>  careful wording for not disrupting existing implementations.  Also,
> we should note that other "radical" changes like changing RA
> frequency (to every 50ms) or removing random delay before sending RAs
> were rejected, mainly based on the "conservative" principle.
> 
> about a new change proposal into 246[12]bis based on the "but isn't
> it unlikely?" type of logic.
> 
>> - its initial Router Solicitation after interface (re-)
>> initialization (D1) [RFC 2461bis] - joining the solicited-nodes
>> multicast address after interface (re-) initialization (D2) [RFC
>> 2462bis] - joining the solicited-nodes multicast address before
>> starting DAD triggered on a multicast RA (D3) [RFC 2462bis]
> 
> 
> Hmm..., regarding D2, it seems we can apply the same approach as D1
> in 2461bis.
> 
> 2461bis for D1.  Recall that our first priority in 2462bis is to
> avoid disruption for existing implementations, not to provide mobile
> nodes an easy way out.
> 
> Besides, even if we remove D3, the mobile node will still face a
> delay in this case, because the responding router will impose a
> random delay before sending an RA.
> 
> Assuming the answer is yes for now, do we still want to remove D2?
> As you pointed out, just removing D2 may not necessarily help mobile 
>  now waiting for IESG approval), I'm personally reluctant to
> introduce the change at this stage.  But if many others also want the
> change (and no one objects to that), I'll try to revise the draft
> once again.
> 
> JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center,
> Toshiba Corp. [email-masked]

---

From: Greg Daley <[email-masked]>
Date: Mon, 30 May 2005 13:01:10 +1000

Hi Christian,

I'll try to keep my response brief.

Christian Vogt wrote:
[cut]
> D1 for MNs would be useless in most situations.

It depends on whether or not the RA can be received after RS without
joining the multicast group.

If the RA can be received, then it doesn't matter so much if the
DAD has been performed at that time, or in the second after.

Please note that RFC2461bis doesn't assume optimistic DAD, and so
may allow RS transmission in this circumstance without a source
address only.  This means that the arriving packets may reduce
movement or change detection time even if 30-70ms MIPv6 RA
intervals aren't implemented.

If the RA indicates that change has occurred, then we're already in 
front, for mobile hosts (and so perhaps the inclusion of the rule
for RS's is valuable).

There may be a problem if optimistic DAD is being used, and an NS/NA
exchange is required to send a unicast RA back to the solicitor.
In that case, a DNA document can talk about the tradeoffs between timers
for MLD, DAD and RS.

I don't think there's a need to change the base documents further.

[cut]
> as D2 and D3 are still there.

The main issue here is that there's an unsolicited RA which many people
may have received, and no indication of movement from L2, so the host is
unsure why the change occurred.

In this case, the host should be conservative in what it sends, and
make use of a delay in order to prevent DAD contention with other
unknown configuring hosts.

The delay D1 is not applicable here (no L2 hint), but a single delay
for DAD NS and MLD may be applicable as you say.

I guessed that the new text in 2462bis covers this nicely, though.

I'm quite happy to look at this sort of feedback making it into DNA
documents though, since host movement is in scope for DNA, and
potentially less directly applicable to IPv6 WG.

Greg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 31 May 2005 03:59:52 +0900

>>>>> On Mon, 30 May 2005 13:01:10 +1000, 
>>>>> Greg Daley <[email-masked]> said:

> unknown configuring hosts.

Thanks, this is exactly what I'm going to explain in this message.  I
believe I don't need to say anything more for rejecting the
elimination of D3 *in rfc2462bis*.  (Again, this does not preclude
future efforts for optimizing the delay further)

> I guessed that the new text in 2462bis covers this nicely, though.

I agree.  If the point is to introduce a single delay for D1 and D2
(note that we cannot make the elimination of D3 for a different
reason), we should be already done.

2461bis-03 reads:

   Before a host sends an initial solicitation, it SHOULD delay the
   transmission for a random amount of time between 0 and
   MAX_RTR_SOLICITATION_DELAY.  This serves to alleviate congestion when
   many hosts start up on a link at the same time, such as might happen
   after recovery from a power failure.  If a host has already performed
   a random delay since the interface became (re)enabled (e.g., as part
   of Duplicate Address Detection [ADDRCONF]) there is no need to delay
   again before sending the first Router Solicitation message.
(Notice the last sentence)

and rfc2462bis-08 reads:

   If the Neighbor Solicitation is going to be the first message to be
   sent from an interface after interface (re)initialization, the node
   SHOULD delay joining the solicited-node multicast address by a random
   delay [...]
(Notice the "If" condition)

I believe it is pretty clear that these specifications indicate a
single delay only applicable to either D1 or D2.

So, are we done (within the scope of 2461bis/2462bis)?

					JINMEI, Tatuya

---

From: Christian Vogt <[email-masked]>
Date: Tue, 31 May 2005 13:52:00 +0200

One last thing below...

 >  after recovery from a power failure.  If a host has already
 > performed a random delay since the interface became (re)enabled
 > (e.g., as part of Duplicate Address Detection [ADDRCONF]) there is no
 > need to delay again before sending the first Router Solicitation
 > message. (Notice the last sentence)
 >
 > and rfc2462bis-08 reads:
 >
 >  delay [...] (Notice the "If" condition)
 >

I didn't doubt that the single delay is correctly specified as such. 
This is very clear in my opinion.

What I was wondering was that, although D[123] are conceptually the 
same, only D1 gets eliminated in the special case that the host is mobile.

Since the WG consensus is not to eliminate D2 and D3 for MNs in 
RFC246[12]bis, eliminating D1 is superfluous as far as I see.  After 
all, the MNs will end up waiting anyway, namely for D2 or D3.  At least 
in the very, very likely case that they autoconfigure a new IPv6 address 
after the handover.

I think Greg's opinion on this is different.  I'm not sure why, though.

Ok, so let's settle this issue.  Thanks for discussing this.

- Christian

JINMEI Tatuya wrote:

 >>>>>> On Mon, 30 May 2005 13:01:10 +1000, Greg Daley
 >>>>>> <[email-masked]> said:
 >
 >
 >
 >>> Well, here is the scenario I am thinking of:  A MN uses
 >>> unsolicited RAs---neither RSs, nor link-layer triggers---to
 >>> detect IP-attachment changes.  Assuming that routers send their
 >>> RAs every 50ms on average, which is what RFC 3775 allows them to
 >>> do, this movement-detection strategy works better than sending
 >>> RSs.  The reason is the random delay for solicited RAs, as you
 >>> say.  Even if the MN would use L2 triggers, it would still have
 >>> to send an RS and await the random RA-delay in order to find out
 >>> the new prefix(es).
 >>>
 >>> So, RFC 3775's frequent (unsolicited) RAs can be leveraged for
 >>> movement detection quite nicely.  But when it comes to
 >>> configuring the new address, the MN ends up having to wait for D2
 >>> or D3 to send the MLD Report.  In other words, eliminating D1
 >>> turns out to be useless as long as D2 and D3 are still there.
 >
 >
 >
 >> The main issue here is that there's an unsolicited RA which many
 >> people may have received, and no indication of movement from L2, so
 >> the host is unsure why the change occurred.
 >
 >
 >
 >> The delay D1 is not applicable here (no L2 hint), but a single
 >> delay for DAD NS and MLD may be applicable as you say.
 >
 >
 >
 >  after recovery from a power failure.  If a host has already
 > performed a random delay since the interface became (re)enabled
 > (e.g., as part of Duplicate Address Detection [ADDRCONF]) there is no
 > need to delay again before sending the first Router Solicitation
 > message. (Notice the last sentence)
 >
 > and rfc2462bis-08 reads:
 >
 >  delay [...] (Notice the "If" condition)
 >