Subject: [mobile-ip] still more iesg comments on the base

From: Jari Arkko <[email-masked]>
Date: Sat, 05 Apr 2003 13:25:31 +0300

For your information: Erik has completed his review and he had a long
list of comments:

   http://www.piuha.net/~jarkko/publications/mipv6/issues/issue289.txt

I've sent an initial response, and there doesn't seem to be any
showstoppers. But we need to work on e.g.

- clarifying that mobile node's must use the currently registered care-of
   address when sending packets
- the configuration knob for disabling RO (discussed earlier in #236)
- destination cache - binding cache relationship needs to be
   worded differently
- whether text is needed to avoid including RH2 on link-local
   packets
- whether hom agents should need to learn information from other
   home agents for the purpose of prefix distribution
- etc.

Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Sun, 6 Apr 2003 11:44:05 -0700

Erik has done a fairly thoughtful review of the material.

"Section 9.5.2 talks about the CN reducing the lifetime
of a binding. Given that the MN might continue sending packets with HAO
until the MN thinks the binding times out it seems unwise for the CN
to limit the lifetime unless it explicitly informs the MN by sending a
BAck."

I disagree with this. I believe that the MN will in most scenarios be
pulling large amounts of data from the network/CN, not the other way around.
So, the MN will not be sending a bunch of packets with a stale HAO
back-to-back to the CN, rather it will likely send a couple before it gets
the BE back from the CN (no binding for HAO) that causes the MN to resynch
to the CN's binding (or lack of binding) state. I like the current design.
The current design has the CN deciding the lifetime of the binding that it
created for the MN. The CN makes no specific guarantee when it sends the BA
that it will keep the binding in its binding cache for the Lifetime
indicated in the BA, that is how it should be IMHO. If the CN wants the
binding to be refreshed, it sends a BRR to the MN before the lifetime of the
binding expires, otherwise the binding will expire. The MN is not
responsible for initiating a refresh of this binding, the CN is entirely
responsible. That contrasts with the home registration binding that the MN
creates in the HA - in that case, the HA has guaranteed that the Lifetime
returned in the BA is how long it will maintain the active binding for the
MN. Also, in that case the MN is responsible for refreshing the home
registration binding. I think this is a good design.

Jari responds:
"Finally, we could prohibit lifetime reduction if A=0."

I wouldn't add that complexity. Please just keep it simple. Currently, the
CN makes no guarantee, A=1 or A=0, about the lifetime of the binding that it
creates for the MN. It may delete that binding at any time, before the
lifetime that it communicated to the MN expires. That is the best/most
flexible design, IMHO. Please remember that some CNs will be embedded
systems and not Linux/etc. servers, and embedded systems actually do have
significant RAM memory constraints, so allowing the CN to arbitrarily free
up the memory/resources that a BCE is using when the CN decides that BCE is
no longer needed is a nice feature, I think.

"Section 11.7.2:
   In addition, when a mobile node receives a packet for which the
   mobile node can deduce that the original sender of the packet has a
   stale Binding Cache entry for the mobile node, the mobile node SHOULD
   initiate a correspondent binding procedure.
How does a mobile node tell that the sender has stale info?
By the fact that the packet was not send to the MN?"

I interpreted this as referring to the case when a MN receives a ULP packet
from the CN via the MN-to-HA tunnel, in which case it knows that the CN
doesn't have an active binding anymore since ULP packets would be route
optimized if the binding existed. But, then I agree that "state Binding
Cache entry" isn't the same as no BCE, so then I don't know what this is
trying to say.

Jari responds:
"Perhaps we should just delete this statement."

I agree with Jari.

Thanks.
- Ed Remmell
Elmic Systems, USA

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jari Arkko
> Sent: Saturday, April 05, 2003 2:26 AM
> To: Mobile IPv6 mailling list
> Subject: [mobile-ip] still more iesg comments on the base
>
>

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 8 Apr 2003 12:20:02 +0200 (CEST)

> no longer needed is a nice feature, I think.

Ed,

I completely agree that the CN doesn't make any guarantees for how long
it will keep a BCE.

My concern however is that the current text might lead a CN implementor
to make choices about the lifetime applied to bindings that will have
a negative performance impact on mobile ipv6.
At a minimum I think it would be useful to inform the implementor
that this is an issue e.g. by adding a warning that
having a binding with a shorter lifetime than in the BU, or
garbage collecting it before the lifetime expires, can lead to
a performance hickup while the binding error exchange takes place
due to the HAO.
Thus I don't think a protocol fix is required, but a heads up to the 
implementors so that they can take the performance impact into account
makes sense.

> If the CN wants the
> responsible.

I don't think this is consistent with the specification.
The specification allows either the MN or the CN to attempt to
refresh an existing binding - the former by sending a BU and the latter by
sending a BR.
But that's orthogonal to the issue above.

  Erik

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 8 Apr 2003 07:56:08 -0700

Erik -

> a performance hickup while the binding error exchange takes place

I agree this warning makes sense to add to the spec.

> refresh an existing binding - the former by sending a BU and the latter by

Hmmm... section 11.7.1:
"Also, if the mobile node wants the services of the home agent beyond
   the current registration period, the mobile node should send a new
   Binding Update to it well before the expiration of this period, even
   if it is not changing its primary care-of address."

There is no similar text w/ regards to the correspondent node binding
procedure.

The Home Agent can include the Binding Refresh Advice option to request the
MN to refresh its home registration binding more frequently.

Section 9.5.5:
"If the sender knows that the Binding Cache entry is still in active
   use, it MAY send a Binding Refresh Request message to the mobile node
   in an attempt to avoid this overhead and latency due to deleting and
   recreating the Binding Cache entry."

When I read the specification, it seems to me that the MN is entirely
responsible for refreshing its home registration binding, however the CN
seems to be primarily responsible (i.e. not the MN) for refreshing a
correspondent node binding by sending the BRR to the MN. The correspondent
node binding consumes resources on the CN. The CN keeps track of whether or
not that binding is actively being used, and based on that can decide
whether to refresh it or not. So, our MN implementation does not actively
refresh correspondent node bindings, but our CN implementation does. Also,
there is the MN optional requirement (section 11.7.2) that says:

"In addition, the mobile
   node MAY initiate the <correspondent binding> procedure in response to
receiving a packet
   that meets all of the following tests:

   o  The packet was tunneled using IPv6 encapsulation.

   o  The Destination Address in the tunnel (outer) IPv6 header is equal
      to any of the mobile node's care-of addresses.

   o  The Destination Address in the original (inner) IPv6 header is
      equal to one of the mobile node's home addresses.

   o  The Source Address in the tunnel (outer) IPv6 header differs from
      the Source Address in the original (inner) IPv6 header.

   o  The packet does not contain a Care-of Test Init message."

Anyways, the guidance I was able to glean from the current spec is that the
MN doesn't actively refresh its CN binding, the CN does. The actual lifetime
that the CN uses for its binding is somewhat unpredictable, so it seems like
it would be difficult for the MN to choose a good binding refresh period -
however, the CN has all of that information, so it would know how frequently
its binding should be refreshed to avoid deleting it prematurely.

Perhaps I wasn't reading between the lines correctly... or perhaps there
isn't enough guidance in the current spec. I agree that it is possible for
the MN to refresh its CN binding whenever it wants to, however this kind of
unsolicited CN binding refresh is not mentioned since there is the BRR
mechanism, initiated by the CN.

Thanks.
- Ed

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 8 Apr 2003 17:48:35 +0200 (CEST)

> There is no similar text w/ regards to the correspondent node binding

Correct. But that doesn't mean it is discouraged.

But I agree that the spec doesn't clearly state the intent of which
end should refresh bindings. My reading between the lines tell me
that either end could do it, and your reading of the lines say that the
spec only talks about the CN doing it.

> Also,

I think this text is a carryover from earlier version where it said that
the MN should always initate a BU when a packet arrives tunneled from
the HA, and theprescriptive notion of the text has been softened.

   Erik

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 08 Apr 2003 21:12:18 +0200

> spec only talks about the CN doing it.

I believe that was the intent all along, yes. One can see a hint
of that intent in this line the second paragraph in section 11.7.2:

    ...The initiated procedures can be used to either update
    or delete binding information in the correspondent node.

Perhaps this could be rendered a bit more evident by perhaps
changing that sentence slightly as follows:

s/node/node (to update the node's location or to refresh the lifetime
of the binding cache entry, for example)./

-gabriel

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Apr 2003 00:40:47 +0300

Here are some of the resolutions I'm proposing for Erik's comments
under issue #289. We still have the following to go through:

- Whether routers should collect other routers information
   or simply rely on their own information for prefix distribution.
   We need WG input!

- 8.2 administrative knob.

- ND and HAO/RH2.

- CN reducing the lifetime of the binding. This was discussed,
   I just didn't have time to process it.

The others I think I have dealt with. Comments welcome. Please
do read the modifications. Unfortunately my site is down today
for some reason, no draft on the web...

 > Major issue:
 > ------------
 >
 > Section 11.3.1 says that one of the mobile node's care of addresses
 > is good enough as a source when sending packets with a HAO.
 > This isn't correct since the CN will verify that the source address
 > is exactly the CoA that the CN has in its BCE. Thus the requirement for
 > the sending is to use the CoA contained in the binding update list
 > and no other CoA.
 > The same issue appears in 11.3.2 where it says:
 >       destination option into the packet, replacing the Source Address
 >       in the packet's IP header with a care-of address suitable for the
 >       link on which the packet is being sent, as described in Section
 >       11.3.1.
 > "with the care-of address used with this correspondent" is better once 11.3.1
 > has been fixed.

Edited from

    "... allowing the IPv6 header's Source Address field to be set to
     one of the mobile node's care-of addresses;"

to

    "... MUST set the IPv6 header's Source Address field to the care-of
     address which the mobile node has registered to be used with this
     correspondent node;"

 > Section 9.1. says:
 >    Destination Cache [12].  That is, any Binding Cache entry for this
 >    destination SHOULD take precedence over any Destination Cache entry
 >    for the same destination.
 > I don't think "precedence" is the best way to describe this.
 > The binding cache provides information that a routing header be added,
 > but the destination cache is still consulted e.g. for path MTU information.
 > (In fact, when the CoA changes it would presumably be useful to carry the
 > path MTU from the destination cache entry for the old CoA to the destination
 > cache entry for the new CoA since it is likely to be a more robust starting
 > point than using the interface MTU on the correspondent.)

Edited as follows: I just left the following piece of text in place, and
deleted the trailing sentence:

    "When sending a packet, the Binding Cache is searched before the
     Neighbor Discovery conceptual Destination Cache~\cite{rfc2461}."

 > Section 9.3.4 says that the BCE SHOULD be deleted due to ICMP errors.
 > But packets with HAO can continue to arrive which will cause a Binding Error.
 > It makes sense to point out this downside in this section and leave the SHOULD
 > in place.

Edited as follows: I added the following text to the end of the
section:

    "Note that if the mobile node continues to send packets with the
     Home Address destination option to this correspondent node, they
     will be dropped due to the lack of a binding. For this reason it
     is important that only persistent ICMP messages lead to the
     deletion of the Binding Cache entry."

 > Section 9.4.3 talks about avoiding route optimization for HOT messages,
 > but there is no corresponding text about avoiding using HOA for HOTI messages
 > in section 11.
 > Is there something generic which can be said about applying HOA and RH type 2
 > to MH messages? I think the only case where RH type 2 makes sense and
 > should be allowed is for a bind ack when the BU was succesful.
 > If there isn't a generic rule that can be applied perhaps text should
 > be added in section 6 for the different MH types e.g.
 > 	A HOT message is never sent using RH type 2 even if there
 > 	is an existing binding, and HOA is never applied to a HOT message
 > 	since HOT messages bypass the binding update list; in essence
 > 	route optimization MUST NOT be applied to HOT messages.
 > and similarly for COT, HOTI, COTI, BU, and perhaps others.
 >
 > That way the specific text in 9.4.3 can be removed and there isn't need
 > to add text elsewhere in section 9 or 11.

Edited to the specification already under issue #269.

 > Section 9.5.1 says:
 >    o  If the Alternate Care-of Address option is present, the care-of
 >       address is the address in that option.
 > [...]
 >    o  Otherwise, the home address is the Source Address field in the
 >       packet's IPv6 header.  This implies that the mobile node is at
 >       home and is about to perform de-registration.
 > The last sentence implicitly states that sending a BU with alt-coa and
 > no HAO is not allowed. If the intent is to forbid that combination
 > please make it explicit. Otherwise drop the last sentence.

Edited by dropping the last sentence.

 > Section 9.5.4 states that Binding Acks don't use the Binding Cache.
 > Do they or do they not use the Binding Update List to determine whether
 > or not to add a HAO?

Edited: this has been resolved as a part of the resolution of #269.

 > Section 10.3.1:
 >    o  Else, if the home address for the binding (the Home Address field
 >       in the packet's Home Address option) is not an on-link IPv6
 >       address with respect to the home agent's current Prefix List or if
 >       the corresponding prefix was not advertised with the Home Agent
 >       (H) bit set, then the home agent MUST reject the Binding Update
 >       and SHOULD return a Binding Acknowledgement to the mobile node, in
 >       which the Status field is set to 132 (not home subnet).
 > The H-bit is set in the RA and not for each prefix as this text assumes.
 > Is the intent just to say that "if the HA is not operating as a HA on that
 > interface"?

Edited to "... if the corresponding prefix was not included in an
advertisement sent with the Home Agent~(H) bit set..."

 > Section 10.6.2 says:
 >    o  The valid or preferred lifetime or the state of the flags changes
 >       for the prefix of the mobile node's registered home address.
 > But when the lifetimes decrement in real time the above would become
 > true every second (the lifetime granularity).
 > I don't think that is the intent.
 > What is the intent?

How about this:

   o  The state of the flags changes for the prefix of the mobile node's
      registered home address.

   o  The valid or preferred lifetime is reconfigured or changes for any
      other reason than advancing real time.

 > Section 10.6.2 has:
 >      MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime),
 > Is this the right thing to do even when a prefix is deprecated?
 > (i.e. it has a zero preferred lifetime).

I think we agreed that the current text is Ok.

 > Section 10.1 is not very clear that (and when) the Binding Update List
 > is used to add HAO to outgoing packets.
 > Compare with section 9.1 which is clear that the Binding Cache is
 > used to add a RH type 2.
 > (Presumably such a statement for HAO would have an exception clause as well
 > since there are packets to which HAO should not be added even there is
 > a BUL entry.)
 > I think the text should capture that when there is a BUL entry for the HoA
 > that is "current" (i.e. the CN has been informed of the latest CoA
 > and optionally the binding ack has been received) that precense of that
 > BUL entry means that packets can be sent directly to the CN with HAO added.

Added this to 11.1:

    The Binding Update List is used to determine whether a particular
    packet is sent directly to the correspondent node or tunneled via
    the home agent (see Section~\ref{mobile-sending}).

Changed the old text in 11.3.1

    The mobile node may send packets to the correspondent node in this
    manner only if the mobile node is aware that the correspondent node
    already has a Binding Cache entry for the mobile node's home
    address. Section~\ref{rxing-hao} specifies the rules for Home Address
    Destination Option Processing at a correspondent node. The mobile node
    needs to ensure that there exists a Binding Cache entry for its home
    address so that the correspondent node can process the packet.

to

    The mobile node needs to ensure that there exists a Binding Cache
    entry for its home address so that the correspondent node can process
    the packet (Section~\ref{rxing-hao} specifies the rules for Home
    Address Destination Option Processing at a correspondent node). The
    mobile node SHOULD examine its Binding Update List for an entry
    which fulfills the following conditions:

    o	The Source Address field of the packet being sent is
	equal to the home address in the entry.

    o	The Destination Address field of the packet being sent
	is equal to the address of the correspondent node
	in the entry.

    o	One of the current care-of addresses of the mobile node
	appears as the care-of address in the entry.

    o	The entry indicates that a binding has been successfully
	created.

    o	The remaining lifetime of the binding is greater than zero.

    When these conditions are met, the mobile node knows that the
    correspondent node has a suitable Binding Cache entry.

 > Some more discription on this front also help nail down the meaning
 > of "binding exists" and "aware that the CN already has a BCE" in section
 > 11.3.1. In both those cases the "current" property is silently assumed.

Edited as above.

 > Section 11.3.1 says:
 >       reverse tunneling.  Detailed operation for both of these cases is
 >       described later in this section and also discussed in [29].
 > but I have no idea what detailed operation the default address selection
 > document offers for reverse tunneling vs. route optimization.
 > Did the last sentence get placed in the wrong part of the text?

Moved at the end of the bullet list.

 > Section 11.4.3 has:
 >    o  If a solicitation has been sent recently, the ICMP Identifier
 >       value MUST be the same as in the solicitation.
 > which seems odd given that solicitations and advertisements might
 > cross in flight and "recently" is not well-defined.
 > Isn't the intent that if an advertisement matches the most recently
 > sent identifier value (and no advertisement has previously matched it)
 > the advertisement is considered to be solicited and is used to update the
 > state about the prefixes.

Edited as: "If the ICMP Identifier value matches the ICMP Identifier
value of the most recently sent Mobile Prefix Solicitation and no
other advertisement has yet been received for this value, then the
advertisement is considered to be solicited and will be processed
further.
	
Otherwise, the advertisement is unsolicited, and MUST be silently
discarded. In this case the mobile node SHOULD send a Mobile Prefix
Solicitation."

 > Otherwise the advertisement is considered to be unsolicited and
 > can only be used to trigger a (rate limited) solicitation?
 > If that is the case it doesn't make sense to have a MUST discard when
 > the ICMP identifier doesn't match.
 >
 > Section 11.7.1 last sentence has a MAY while referring to some possible
 > future work in appendix B.5. This makes no sense since it isn't possible
 > to implement this until the work outlined in B.5 has resulted in a
 > specification. Thus this needs to be reworded to refer to this
 > as "Perhaps this can be solved in the future using the scheme outlined
 > in appendix B.5" or something along those lines.

Edited as "(Mechanisms outlined in Appendix~\ref{remote-cfg} may in
the future allow mobile nodes to acquire new home addresses to replace
the one for which Status 134 was received.)"

 > Section 11.7.2:
 > By the fact that the packet was not send to the MN?

Statement deleted.

 > Section 11.7
 >    o  The packet does not contain a Care-of Test Init message.
 > Why is CoTI special? Aren't there other RR procedure messages that should
 > be subject to the same exclusion?

Edited as "The packet does not contain a Home Test, Home Test Init,
Care-of Test, or Care-of Test Init message."

 > Section 11.7.2:
 >    A mobile node MAY also choose to keep its location private from
 >    certain correspondent nodes, and thus need not initiate the
 >    correspondent binding procedure.
 > While the document uses "location" all over to refer to "topological location"
 > I think in a sentence about location privacy it would be good to spell
 > this out to avoid confusing this with geographical location privacy.

Corrected.

 > Section 11.7.2:
 >    A Binding Update is created as follows:
 >    o  The Source Address of the IPv6 header MUST contain the current
 >       care-of address of the mobile node.
 > Is use of alt-coa explicitly forbidden?

Edited as "The current care-of address of the mobile node MUST be sent
either in the Source Address of the IPv6 header or in the Alternate
Care-of Address mobility option."

 > Section 11.7.3:
 >    o  If the Status field indicates that the Binding Update was rejected
 >       (the Status field is greater than or equal to 128), then the
 >       mobile node SHOULD record in its Binding Update List that future
 >       Binding Updates SHOULD NOT be sent to this destination.
 >
 >       Optionally, the mobile node MAY then take steps to correct the
 >       cause of the error and retransmit the Binding Update (with a new
 >       Sequence Number value), subject to the rate limiting restriction
 >       specified in Section 11.8.
 > I thought e.g. responding to 135-138 errors was more than optional.
 > Requiring that the MN give up (SHOULD NOT) is odd in any case.
 > Only if the MN either doesn't have a recourse or chooses not to
 > take optional recourse, is it the case that it SHOULD NOT send further BUs.

Rewritten as: "If the Status field indicates that the Binding Update
was rejected (the Status field is greater than or equal to 128), then
the mobile node can take steps to correct the cause of the error and
retransmit the Binding Update (with a new Sequence Number value),
subject to the rate limiting restriction specified in
Section~\ref{rate-limit}. If this is not done, or it fails, then the
mobile node SHOULD record in its Binding Update List that future
Binding Updates SHOULD NOT be sent to this destination."

 > Section 11.8:
 >
 > I assume that this retransmission behavior should apply to home agent discovery
 > as well. The document seems silent on such retransmissions.

I think we agreed not to change this.

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 15 Apr 2003 15:26:54 -0700

Jari -

I reviewed your proposed modifications, they look fine. I can go either way

>    I just didn't have time to process it.

I know I argued before that I thought it was nice to have the flexibility
that the current MIPv6 spec has w/ regards to the binding lifetime on the
CN, but if we want to tighten this part up and make it more of a SHOULD
requirement that the CN SHOULD respect (and thus not arbitrarily shorten)
the lifetime of the binding that it communicates back to the MN in a BA,
then I'm OK with that. However, I would not be in favor of making this a
MUST requirement for the CN.

The following is possibly more detail that is necessary, but it is correct,
so I like it just the same ;-)

Thanks.
- Ed

> Sent: Tuesday, April 15, 2003 2:41 PM
> To: Erik Nordmark
> Cc: Ed Remmell; Mobile IPv6 mailling list
> Subject: Re: [mobile-ip] still more iesg comments on the base
>
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 15 Apr 2003 15:44:21 -0700

>    or simply rely on their own information for prefix distribution.

current IPv6 specifications do not prohibit routers on
the same link from advertising different prefixes. I 
thought that was an IPv6 feature. since Home Agents are
also routers, section 10.6.1 was added to make sure we 
dont break this IPv6 feature :-) Erik's proposal is that
we simplify things by configuring same set of prefixes
on all the Home Agents on a link and get rid of section
10.6.1.

I am fine with Erik's suggestion.

> - ND and HAO/RH2.

this is obvious, right? HAO or RH2 should never be added to 
neighbor discovery messages. 

>    I just didn't have time to process it.

I think we can add some text which says, the CN must send a
binding ack (irrespective of the Ack bit) if it reduces the
lifetime of the binding. the MN should be ready to process
such binding acks even if didnt set the Ack bit.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Apr 2003 16:49:22 +0300

This e-mail is a response to Vijay but it also contains
proposed resolutions to the remaining issues that Erik
raised.

> I am fine with Erik's suggestion.

(Actually, I think Erik's suggestion is in line with the
IPv6 feature. While routers can have different prefixes,
they do not forward other router's prefix information.)

Here's a suggested rewrite of Section 10.6.1:

    Mobile IPv6 arranges to propagate relevant prefix information to the
    mobile node when it is away from home, so that it may be used in
    mobile node home address configuration, and in network renumbering.
    In this mechanism, mobile nodes away from home receive Mobile Prefix
    Advertisements messages with Prefix Information Options, which give
    the valid lifetime and preferred lifetime for available prefixes on
    the home link.

    The messages relayed to the mobile node are the Router Discovery
    messages the home agent is itself sending on the home link.  The home
    agent SHOULD construct the aggregate list of home subnet prefixes as
    follows: Copy prefix information defined in the home agent's
    AdvPrefixList on the home subnet's interfaces to the aggregate list.
    Also apply any changes made to the AdvPrefixList on the home agent to
    the aggregate list.

    If there are multiple home agents, differences in the advertisements
    sent by different home agents can lead to an inability to use a
    particular home address when changing to another home agent.  In
    order to ensure that the mobile nodes get the same information from
    different home agents, it is desired that all the home agents on the
    same link be configured in the same manner.

    To support this, the home agent monitors prefixes advertised by
    itself and other home agents routers on the home link.  Observed
    differences SHOULD be logged.

> neighbor discovery messages. 

Ok. New text for 11.3.1:

   "o  While not at its home link, the mobile node MUST NOT use the Home
       Address destination option when communicating with link-local or
       site-local peers, if the scope of the home address is larger than
       the scope of the peer's address.

       Similarly, the mobile node MUST NOT use the Home Address
       destination option for IPv6 Neighbor Discovery [12] packets."

Changed text for 9.3.2:

   "If the sending node has a Binding Cache entry
    for this address, the sending node SHOULD use a type 2 routing header
    to route the packet to this mobile node (the destination node) by way
    of its care-of address.  However, the mobile node MUST not do this in
    the following cases:

    o  When sending an IPv6 Neighbor Discovery [ref]  packet.

    o  Where otherwise noted in Section 9.4.3."

> such binding acks even if didnt set the Ack bit.

Actually, it seems that Erik & Ed discussion lead to the
direction of simply adding a warning that if the CN deletes
the BCEs or reduces their lifetime too eagerly, this may
have a harmful effect. Is this sufficient or should we also
require an Ack to be sent?

Proposed text:

   Note that if the mobile node did not request a Binding
   Acknowledgement, it is not aware of the selected shorter lifetime.
   The mobile node may thus use route optimization and send packets with
   the Home Address destination option. As discussed in
   Section 6.2, such packets will be dropped if there is no
   binding. This situation is recoverable, but can cause temporary packet
   loss.

> 8.2 administrative knob

After some thought, maybe we should simply make this an optional
knob. I changed the MUST to a SHOULD.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Apr 2003 11:33:47 -0700

>    Also apply any changes made to the AdvPrefixList on the home agent to

why do we need the aggregate list then? if the aggregate list is
going to contain the same set of prefixes that the Home Agent is
already configured with, you dont need a separate list maintained
by each Home Agent. when a Home Agent receives a mobile prefix
solicitation, it has to just include all the IPv6 prefixes
configured on its interfaces in the mobile prefix advertisement.

>    differences SHOULD be logged.

I favor adding the above two paragraphs and removing the aggregate
list.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sat, 19 Apr 2003 11:36:41 +0300

> configured on its interfaces in the mobile prefix advertisement.

Now that you mention it, the aggregate list does seem unnecessary
after this change.

Here's the new beginning of Section 10.6.1:

   Mobile IPv6 arranges to propagate relevant prefix information to the
   mobile node when it is away from home, so that it may be used in
   mobile node home address configuration, and in network renumbering.
   In this mechanism, mobile nodes away from home receive Mobile Prefix
   Advertisements messages. These message include Prefix Information
   Options for the prefixes which appear in the AdvPrefixList on the
   home subnet interface(s) of the home agent.

> I favor adding the above two paragraphs and removing the aggregate

See above for the new text. Where the aggregate list has been referred
to elsewhere, I either reformulated the text to refer to 10.6.1 instead,
or used "AdvPrefixList on the home subnet interface(s) of the home agent."

Jari