Subject: Re: [MOBILE-IP] Mobile IPv6 questions

From: "Powell, Ken" <[email-masked]>
Date: Thu, 13 Apr 2000 15:17:52 -0400

>    Sections 9.7 and 10.16 describe how the home agent supplies
>    the mobile node with router advertisement updates whenever
>    prefixes on the home network change. If I understand this
>    correctly, the prefixes covered by these requirements include
>    prefixes advertised by other routers on the home subnet in
>    addition to the home agent's own prefixes.
>
> => a home agent is a router then it should advertise the same
> prefix set than other routers on the home subnet. I don't know
> what you name the home agent's own prefixes.

I agree that this will be the typical configuration. However,
I don't know of any requirements in the IPv6 specs that mandate
all routers on a link advertise the same set of prefixes. RFC
2461 section 6.2.7 states:

  "Note that it is not an error for different routers to
   advertise different sets of prefixes"

Section 9.7 of the Mobile IPv6 draft indicates that it was
intended to support routers advertising different prefixes:

  "The home agent determines these conditions based on its
   own configuration as a router and based on the Router
   Advertisements that it receives on the home link."

I think some of your other responses were based on the
assumption that routers will advertise a consistent set
of prefixes. I guess before we can resolve the details,
we need to know if the Mobile IPv6 spec should or should
not impose this restriction on the home subnet configuration.
I don't know if this issue was discussed already by this group.
If so, what was the resolution? If not, what do others think
about this?

>
>    I think more details are needed on how the home agent should
>    maintain its list of prefixes
>
> => I think it should use standard management and router renumbering
> as other routers.

Yes, if routers on the home subnet advertise the same set of prefixes.
Otherwise, we need additional mechanisms to keep the set of home subnet
prefixes available to the mobile node consistent.

>
>    and how it keeps this list synchronized with the mobile node's list
>    of home network prefixes.
>
> => the issue is at the mobile node's side and is covered by
> 9.7 and 10.16.

Yes, these sections do cover some of what is needed, specific
problems were listed below.

>
>    Sections 4.3, 5.1, 9.3, and 9.5 describe how the mobile node
>    sends a Router bit to the home agent which the home agent must
>    in turn use for the IsRouter bit on proxy neighbor advertisements
>    for the mobile node. Why is this done? The mobile node can't
>    continue to function as a normal router to other nodes on the
>    home subnet can it?
>
> => the mobile node can be either a host or a router then the home
> agent needs to know if it is a host or a router when it sends
> proxy NAs (because of the IsRouter bit). The router bit in binding
> updates provides this information.

I asked this question because of the role the IsRouter bit plays
in Neighbor Discovery. Specifically, the sole function of the
IsRouter bit is to signal to hosts on the home link that a node
which was previously acting as an on-link router is no longer
capable of accepting messages on the link for forwarding. RFC
2461 section 7.3.3 states:

  "When a node detects that a neighbor has changed from being a
   router to being a host, the node MUST remove that router from
   the Default Router List and update the Destination Cache as
   described in Section 6.3.5.  Note that a router may not be
   listed in the Default Router List, even though a Destination
   Cache entry is using it (e.g., a host was redirected to it).
   In such cases, all Destination Cache entries that reference
   the (former) router must perform next-hop determination
   again before using the entry."

I don't believe RFC 2461 accounted for mobile routers. It seems
to me that the above host processing makes just as much sense
when a neighboring mobile router goes off-link as when a
neighboring router switches from being a router to a host.

>
>    Should mobile nodes be capable of booting and establishing a
>    binding to a home agent without a direct connection to the home
>    subnet?
>
> => yes, there must be a connection but an indirect one is enough.
>
>    If so, this spec should define how a mobile node could
>    autoconfigure its Home Address from a remote site.
>
> => It cannot do that without human help. In fact it cannot decide
> if it is at home or in visit with zero knowledge. 9.7 and 10.16
> provides only a way to "follow" home prefix changes when the mobile
> is up (then the mobile can update its configuration).
> If the home prefix has changed when the mobile was stopped then
> a protocol not described in the I-D must be used (some kind of
> mobile management protocol/tool?)

Agreed. However, I think this I-D should be able to cover how
to initialize its state on the home agent and the mobile node
from a limited amount of information that is relatively easy
to configure. For example, start with the assumption that the
mobile node can always get the Home Agent's Anycast Address.

>
>    I don't think we can assume the home network prefix will remain
>    unchanged while a mobile node is off-line.
>
> => but this is assumed by the I-D. In fact prefix changed are supposed
> to be rather infrequent and prefix lifetimes very large (defaults are
> 7 and 30 days).

30 days isn't a long time to leave a mobile device unused on a
shelf in someone's closet. Some mobile nodes are going to go off-line
for extended periods of time, beyond the transition period of a
renumbering event. Mobile devices need to handle this possibility
automatically when powered up.

>
>    One possibility is to store the home
>    network anycast address in DNS. The mobile node could then query
>    the home agent anycast address and combine its prefix with
>    the mobile node's interface id to generate a Home Address.
>
> => there are many solutions, DNS is a good one if the mobile knows
> the home network name (but remember that it must know something).

Agreed.

>
>    Comments on Specific Sections:
>
>    Page 14:
>
>      Should section 4.3 (Conceptual Data Structures) define a place
>      where the home agent would store the state of all prefixes
>      advertised by other routers on the home subnet?
>
> => the home agent should act as a standard router for this.

Yes, but only if all routers on the home subnet advertise the
same set of prefixes.

>
>    Page 15:
>      "must be performed modulo 2**16"
>
>      What does this phrase mean?
>
> => ((short)((a) - (b)) > 0) in C with 16 bit long shorts.

OK. This makes sense. I'm not a mathematician, but I don't
believe the term "modulo" accurately represents this.
I don't have a better suggestion, so would it make sense
to keep the term and add an explanation like this somewhere
in the spec to clarify it?

>
>    Page 42 penultimate paragraph:
>      "In a solicited Router Advertisement, a router MUST
>       include at least one Prefix Information option with
>       the router Address (R) bit set."
>
>      This looks like a requirement on all IPv6 routers. I
>      understand why this is a MUST for mobile agents, but
>      I don't get the reasoning for routers that are not acting
>      as mobile agents.
>
> => the rationate at the beginning of 6.2 is only about home agents
> then I agree: R bit must be defined for routers but the MUST is only
> for home agents. But I know some situations where router addresses
> are very useful then I'd like to have a SHOULD for routers which are
> not home agents.

I don't understand why "SHOULD" as opposed to "MAY". I don't see
why a router implementation that has no mobile agent support should
do this.

>    Page 59 Section 9.1:
>
>      Should this section describe how the home agent saves address
>      prefixes advertised by other routers on the home network for
>      later forwarding to the mobile node?
>
> => same: home agents are routers.
>

Yes, and it gets back to the same prefix issue.

>
>    Page 62 Section 9.4 (Primary Care-of Address Registration):
>
>       Is it safe to assume when a mobile node sends the first
>       Binding Update to a particular home agent, that the mobile
>       node will always have the same set of prefixes defined for the
>       home subnet as the home agent?
>
> => it is because renumbering are rare events and 9.7 & 10.16 signal
> them to mobile nodes.

This question was intended to cover two possible situations:
  o Two home agents exist on a link that recognize different
    sets of prefixes.
  o A renumbering event occurs while a mobile node looses
    access to the internet.

I agree, such events should be rare, but I think they are worth
dealing with. The first one is either a bug or a configuration
error. In any event, it seems possible and I think the protocol
should have a means to recover at least as effectively as an
on-link node could recover.

>
>       If not, then should the home
>       agent send a router advertisement with all known home subnet
>       prefixes to the mobile node with the first Binding
>       Acknowledgement? This will account for prefixes the home
>       agent knows which the mobile node doesn't.
>
> => this is a nice idea.
>
>    Page 63 4th paragraph:
>      "Furthermore, if the Prefix Length field in the Binding Update
>       is non-zero, then the lifetime for the Binding cache entry MUST
>       NOT be greater than the minimum remaining valid lifetime for all
>       subnet prefixes on the mobile node's home link."
>
>      Would this requirement force a small period where communication
>      to the mobile node through the home agent will fail when the
>      home network completes a renumbering process?
>
> => I think the home agent should send binding requests when a prefix
> (then binding cache entries) expires but binding
> acknowledgements trigger new binding updates in such cases
> (then a SHOULD is enough, it just makes things more reliable).
>
>      At the end of a renumbering process, the valid lifetime of the
>      old home network prefix counts down to zero. Given this
>      requirement, the lifetime of the mobile agent's Binding
>      Cache entry for a mobile node must also count down to zero,
>      after which the Binding Cache entry must be deleted making
>      the mobile node unreachable.
>
> => the idea is to flush cache entries for an expired prefix.

I would like to distinguish between the subnet prefix associated
with the home address on the mobile node's Binding Update, and
the other subnet prefixes on the home network. I agree that when
the former times-out, the binding cache entry for the mobile node
should be flushed. I don't think the binding between the mobile
node and the home agent should be purged when other subnet
prefixes on the home network timeout. They are not needed
to maintain communication between the home agent and the mobile
node, and the mobile node has individual timers on the other
home addresses which will expire on their own.

As an alternative, would it make sense to add a restriction
in sections 10.6 and 10.8 that the Lifetime field sent on
a Binding Update SHOULD not be greater than the remaining
lifetimes of the home address and the care-of address of the
mobile node?

>    Page 65 last paragraph:
>      "The home agent examines the value of the Prefix Length field
>       in the new "home registration" Binding Cache entry. ... If,
>       instead, this field is nonzero, then the following step is
>       carried out for each address for the mobile node formed from
>       the interface identifier in the mobile node's home address in
>       this binding (...), together with each one of the subnet
>       prefixes currently considered by the home agent to be
> on-link..."
>
>      What does "currently considered by the home agent to be on-link"
>      mean? Is it restricted to prefixes defined in the home agent's
>      own AdvPrefixList (per RFC 2461), or does it also include the
>      list of on-link prefixes advertised by other routers on the home
>      network?
>
> => as a router the home agent should have the same on-link prefix set
> than other routers (RFC 2461, 6.2.7 "Router Advertisement
> Consistency").
> Note RFC 2461 is not very clear about active actions (beyond the scope
> of this document :-).

This question hinges on the router prefix assumption.

>
>    Page 68 section 9.7:
>
>      RFC 2461 defines that a router has the following management
>      variables for each prefix.
>
>          AdvValidLifetime
>               as a time that decrements in realtime
>               as a fixed time
>          AdvPreferredLifetime
>               as a time that decrements in realtime
>               as a fixed time
>
>      How do the various flavors (fixed vs decrementing) of these
>      timers on the home agent impact the timing for sending router
>      advertisements from the home agent to the mobile node? Page 69
>      of the Mobility draft states that a router advertisement needs
>      to be sent when the "preferred or valid lifetime for an existing
>      prefix on the home link is reduced". This doesn't account for a
>      prefix for which the router is decrementing the time
> continuously.
>
> => I agree
>
>      When a mobile agent receives a router advertisement from
>      another router on the home subnet, does it treat the received
>      Valid Lifetime and Preferred Lifetime as fixed or decrementing?
>      I would think given the lack of other information, it should be
>      treated as decrementing.
>
> => RFC 2461 6.2.7 provides the answer (use the local
> fix/decrement mode).

This gets back to the router prefix assumption. I was wondering
what to do if the home agent receives a prefix from another
router that is not defined on the home agent. There is no
fix/decrement flag in the router advertisement.

>
>      What should the mobile agent set the following fields to when
>      sending a router advertisement to a mobile node?
>
>         M (managed address configuration flag)
>         O (other stateful address configuration flag)
>         H (home agent flag)
>         Router Lifetime
>         Reachable Time
>         Retrans Timer
>         Prefix Information
>            L (on-link flag)
>            A (autonomous address configuration flag)
>            R (router address flag)
>            Valid Lifetime
>            Preferred Lifetime
>            Prefix
>
> => I don't see a reason to send something different than on
> the home link?

I guess the possible issues I can think of are:

  Retrans Timer:  I don't know how address timers are to be
                  handled on mobile nodes. For now, I assume
                  the mobile node continues to time-out home
                  addresses as if they were on-link. Given that,
                  the router advertisement must be retransmitted
                  periodically by the home agent. I understand
                  the time between retransmissions would be
                  much greater than on-link. What should this
                  time period be? Should this field in the
                  advertisement be adjusted accordingly?

  L (on-link flag): The mobile node is no longer on-link.
                  As far as I can tell, all communication
                  to nodes on the home subnet will work
                  exactly like communication to any other
                  off-link node.

I think the spec should explicitly state the remaining fields
are transmitted exactly as if the message were sent on-link.

>
>    Page 80 Section 10.7:
>
>      Should a mobile node get its home network anycast address from
>      DNS as opposed to constructing it from the previously known home
>      network prefix? This would allow a mobile node to more easily
>      recover from renumbering events on the home network if it happens
>      to be disconnected while the renumbering event occurs.
>
> => "previously" is only a way to know the home network prefix
> (and the way to know it is not specified by the I-D) then you MAY
> do what you'd like...

By "previously", I intended to convey that the mobile node remembers
the numeric form of the home network prefix last used in non-volatile
memory. I don't think this would be a good thing to do. The prefix may
change.

>
>    Page 86 Section 10.12:
>
>      This section does not define what the mobile node should do
>      with the Lifetime field in the Binding Acknowledgement.
>
> => send a binding update of course.
>
>      The only statement I found in the spec is in section 5.2:
>
>       "...if the mobile node requires home agent service from
>        this node beyond this period, the mobile node MUST send
>        a new Binding Update to it before the expiration of this
>        period (...), in order to extend the lifetime".
>
>      Should the mobile node reduce the lifetime field in it's Binding
>      Update List entry for the home agent to the lifetime in the
>      Binding Acknowledgement?
>
> => perhaps a statement about lifetime update should be added in 10.12
> (I believe it is the case because you ask for a clarification).

Yes.

>
>    Page 89 last paragraph:
>      "... although due to separation between preferred lifetime and
>       valid lifetime, such changes should not affect most
> communication
>       by the mobile node, in the same way as for nodes that
> are at home."
>
>      What does this mean?
>
> => just the idea to have preferred and valid lifetimes provides
> smooth renumbering, ie. the home address should not become invalid
> in a savage way...

OK, I understand now. I had trouble parsing the sentence before.

>
>    Page 90 3rd paragraph:
>      "In addition, if processing this Router Advertisement resulted in
>       the mobile node configuring a new home address..."
>
>      Sanity check: Lets assume I have a home subnet with the prefix
>      3ffe:1200:1:2::/64. I need to renumber it to 3ffe:1300:1:2::/64
>      while a mobile node using my subnet is wandering around the world.
>      I change my routers on my home network to advertise:
>
>       3ffe:1200:1:2::/64  Valid lifetime = 2592000 (30 days) decrementing
>                           Preferred lifetime = 0
>       3ffe:1300:1:2::/64  Valid lifetime = 2592000 (30 days) fixed
>                           Preferred lifetime = 604800 (7 days) fixed
>
>      Upon receipt of the new router advertisement from the home agent,
>      the mobile node should switch its Home Address from the deprecated
>      address (3ffe:1200:1:2::/64) to the preferred address
>      (3ffe:1300:1:2::/64). It does this by sending a Binding Update option
>      for the old home address with zero Lifetime to force the home agent
>      to delete the old entry, followed by another Binding Update option
>      with the new home address. I'm assuming the Binding Update options
>      have a non-zero Prefix Length field. If the old home address is not
>      deleted first, having the home agent perform duplicate address
>      detection with all home subnet prefixes will cause problems. Is this
>      right?
>
> => I don't believe. This is not very different of a case where the
> mobile is stopped and reconfigured during the renumbering: there is
> a stale entry which be flushed at the end of its lifetime (less than
> 30 days :-). The duplicate address detection is done on the link,
> not inside the home agent, and can give strange results with more
> than one home agent on the link and long lifetimes for cache entries.

I see your point. I'm still confused how the home agent should handle
the following situation (extension of example above):

Binding Cache entry for mobile node:
   Home Address:     3ffe:1200:1:2:0a00:2bff:fe00:1122
   Care-of Address:  3ffe:5555:0:1:0a00:2bff:fe00:1122
   Lifetime:       604800
   Home Reg Flag:    set
   Prefix Length:    64

After getting the router advertisement for the renumbering
event, the mobile node sends a message with:

   Source Address:        3ffe:5555:0:1:0a00:2bff:fe00:1122
   Home Address:          3ffe:1300:1:2:0a00:2bff:fe00:1122
   Binding Update w/
     (A)cknowledge:       1
     (H)ome Registration:
     (R)outer:            0
     (D)uplicate Addr:    1
     Prefix Length:       64
     Sequence Number:     5
     Lifetime:            604800

Due to the specification of the prefix length in the Binding
Update, the resulting Binding Cache Entry would cover all home
subnet addresses with interface identifier "0a00:2bff:fe00:1122".
This means there will be two Binding Cache Entries to cause
forwarding of the mobile node's original home address. Is there
a recommended way to avoid this duplicate coverage? If not,
should the home agent recognize this as a duplicate entry and
purge the old one?

>
>      Can both Binding Update options (to delete old and create new)
>      be sent in the same IPv6 message?
>
> => I don't think so because there is only one home address per message
> (but I'd like to have a statement against duplicate home
> address options).

OK.

>
> Regards
>
> [email-masked]
>

Ken Powell
Compaq Computer Corporation

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Apr 2000 22:01:53 +0200

In your previous mail you wrote:

   I agree that this will be the typical configuration. However,
   I don't know of any requirements in the IPv6 specs that mandate
   all routers on a link advertise the same set of prefixes.

=> there is no "MUST" because it is not necessary to have the same set
for all the routers (ie. union is an easy operation then hosts will
not be confused by different and compatible sets) but I believe the sets
SHOULD be consistent.
 The default prefix list announced by a router is "all prefixes that
the router advertises via routing protocols as being on-link for the
interface from which the advertisement is sent". This gives in common
case the whole set of prefixes of the link.

   RFC 2461 section 6.2.7 states:

=> for me "no error" is requirement level below/weaker than a "MUST NOT".

=> and section 9.7 indicates the home agent should send changes
for any prefixes of the link, the list is built by the union
of configured prefixes on the home agent and prefixes listen
on the link in router advertisements. Things are more simpler
if both lists in the union are the same.

=> mobile IPv6 spec imposes this restriction for router advertisements
sent to the mobile node in case of an "important" change. There is
nothing about other router advertisements...

=> if router management tools are not enough then the home agent should
look at prefixes announced by router advertisements from other routers
(cf section 9.7).

=> there is two independent parts in "being a router":
 - being an on-link router (this function uses the link-local address
  then will stop when the router goes off-link. Some implementations
  impose the gateway field of a route to be a link-local address,
  this is not stupid because an off-link router can't receive then
  forward packets on the link)
 - being involved in a protocol as a router (in general such a protocol
  is a routing protocol but there are other examples). In this case
  an address with a scope larger than the link is used and if the
  protocol looks at the neighbor discovery stuff then the IsRouter
  flag must be preserved (ie. there is no good reason than a router
  which goes off-link MUST become a host then the IsRouter flag
  MUST be transmitted in binding updates).
Note: the IsRouter should be reset in proxy neighbor advertisements
for the link-local address, for instance in duplicate address detection.
Perhaps a SHOULD for a proxy router advertisement with a zero lifetime
should be added too?

   However, I think this I-D should be able to cover how

=> I agree this is useful but I think this is out of the scope of the I-D.

=> it is simpler to add the unknown prefixes to the home agent prefix list
(hosts will not see the difference) but a clarification is needed.

   > are very useful then I'd like to have a SHOULD for routers which are

   I don't understand why "SHOULD" as opposed to "MAY".

=> I think you don't understand because of this next statement:

   I don't see why a router implementation that has no mobile agent
   support should do this.

=> because this gives a nice way to know a global address of a router:
router advertisements carry only the link-local address and to take
a prefix and the interface ID from the link-local address is *not*
a reliable way to get one.
There are some situations where it is useful:
 - management (it solves the topology discovery issue described by
 Jean-Luc Richier, you know routers the link, you send SNMP queries
 to know further routers and you get only unusable link-local addresses,
 with global or site-local addresses you can queries second then higher
 layer routers).
 - point-to-point links: some OSs want to get both addresses when you
 add a new prefix.
 - just ask in the IPng list for many other examples...

   I would like to distinguish between the subnet prefix associated
   with the home address on the mobile node's Binding Update, and
   the other subnet prefixes on the home network.

=> the problem is this distinction doesn't work for connections which
are not initiated my the mobile node, for instance when the DNS has
the whole set of home addresses.

   I agree that when the former times-out, the binding cache entry
   for the mobile node should be flushed. I don't think the binding
   between the mobile node and the home agent should be purged when
   other subnet prefixes on the home network timeout. They are not needed
   to maintain communication between the home agent and the mobile
   node, and the mobile node has individual timers on the other
   home addresses which will expire on their own.

=> you forget the home agent is a correspondent too then the binding
cache entry must be flushed as soon as an address in the set timeouts
(correspondents are simpler because they have one home address by entry,
the prefix length stuff gives one entry for the whole set but this has
a cost).

=> this is not an alternative and is an issue when advisertised
lifetime are ridiculously short, for instance to help a broken
movement detection...

   > => RFC 2461 6.2.7 provides the answer (use the local fix/decrement mode).

   This gets back to the router prefix assumption.

=> this is an argument in favor of it because to look at router
advertisments don't give all infos (thank for the proof :-).

=> the retrans timer is for NUD and address resolution, the mobile node
can't do something useful with it...

=> idem, it doesn't matter but there is an interesting case:
 - there is only one prefix announced on the link (what you call
   the home subnet?)
 - this prefix is off-link, ie. there are nodes in the prefix on other links
 - the mobile node is connected to one of these links.
IMHO the mobile node is still at home and routing between nodes in the
prefix must be done with host routes: this is like paging/micro mobility
and needs draft-nordmark-ipv6-aaa-hooks-00.txt registration to work...

=> SHOULD or MUST? The I-D says "no other options"...

=> we agree, DNS is a superior way but again this is out of the scope.

   Is there a recommended way to avoid this duplicate coverage?

=> none... Worse, if the mobile node reboots and sends a fresh home
registration then the home agent can be confused and rejects it because
of a bad sequence number (this point is supposed to be solved by the
security stuff which resets SAs before but this is in old minutes,
not in the spec).

   If not, should the home agent recognize this as a duplicate entry and
   purge the old one?

=> same answer, and the issue is open when there is more than one home agent.

Regards