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

From: "Powell, Ken" <[email-masked]>
Date: Tue, 9 May 2000 17:23:43 -0400

Sorry for the slow turn-around on this, I was sidetracked
by vacation and other priorities at work.

>
>    RFC 2461 section 6.2.7 states:
>
>      "Note that it is not an error for different routers to
>       advertise different sets of prefixes"
>
> => for me "no error" is requirement level below/weaker than a
> "MUST NOT".

I read it to mean different routers "MAY" 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."
>
> => 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.

I agree that things are simpler if both lists are the same,
but I don't think we can just assume they are without stating
that clearly in the Mobile IPv6 spec.

>    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.
>
> => mobile IPv6 spec imposes this restriction for router advertisements
> sent to the mobile node in case of an "important" change.

I think you may have misinterpreted my statement. I meant to ask
should Mobile IPv6 impose a restriction that all routers on the
home subnet advertise a consistent set of prefixes?  If not, then
the Mobile IPv6 spec needs to provide more details about how to
relay prefix information from all routers on the home subnet to
the mobile node.

Perhaps there could be an alternative restriction that a Mobile
Agent's interface needs to be configured with all possible prefixes
advertised on the home link. Other routers don't.

I wonder if there are any other ways to solve this problem.

> => There is
> nothing about other router advertisements...

My term "other router advertisements" was intended to mean
"router advertisements that the mobile agent receives on the home
link".

>
>    >    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.
>
> => 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).

Agreed, but which way should it be?

>
>    >    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.
>
> => 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).

Thanks, I didn't think of this second possible use of IsRouter.

> 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
>    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 agree this is useful but I think this is out of the
> scope of the I-D.

Perhaps it would help if I backed up a little. The Mobile IPv6
draft explains how to handle many parts of stateless address
autoconfiguration between a mobile node and the home network.
This led me to believe that Mobile IPv6 aught to work with a
home subnet that runs stateless address autoconfiguration only.
I tried to understand how a Mobile IPv6 node would initialize
its addresses on power-up using stateless address auto-
configuration when away from home. The steps I came up with
were:

  1) Get the home network mobile agent anycast address.
     (Method for this is beyond the scope of this spec)

  2) Send Home Agent Address Discovery Request message
     to home network.

  3) Receive Home Agent Address Discovery Reply message.

Now I'm stuck. I still need to:

  4) Autoconfigure the mobile node's home network global
     addresses from router advertisements sent by the
     home agent. This cannot be done without the primary
     care-of address binding due to the way router
     advertisements are tunneled.

  5) Create the primary care-of address binding. This
     cannot be done without the mobile node having a
     global address on the home network.

What information can I expect the mobile node have to break
this deadlock? Is my reading of how this should work way off?

>
>    >    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.
>
> => 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.

I'm not sure exactly what you mean. Would the home agent
dynamically add the prefix from another router on the link
to its own list and automatically start advertising that prefix?

>
>    >    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 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...

This is plenty, I'm convinced. "SHOULD" sounds good.

>
>    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.

The latest draft went a long way to clear up my concerns here.
If I read the changes right, the lifetime of bindings with
correspondent nodes is no longer limited to be less than the
lifetime of the binding with the home agent. I was worried
that a mobile node would have to drop all bindings to all
nodes at the end of a renumbering process on the home network.
That won't happen now.

>
>    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).

Good point.

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

Yes, but this can be reasonably handled. It just has to be
defined somewhere so everyone does it the same way if its done
at all.

>
>    >      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?
>
> => the retrans timer is for NUD and address resolution, the
> mobile node
> can't do something useful with it...
>
>      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.
>
> => 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...

Looking at it again, I agree. These fields don't need any special
handling.

>
>    I think the spec should explicitly state the remaining fields
>    are transmitted exactly as if the message were sent on-link.
>
> => SHOULD or MUST? The I-D says "no other options"...

Good question, I can see arguments for either. A SHOULD would
allow home agent developers to put in value-added features they
may think of later. Would the home agent seriously break neighbor
discovery or stateless address autoconfiguration by sending
different values of these fields to the mobile node?

>
>    >    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.
>
> => we agree, DNS is a superior way but again this is out of the scope.

OK.

>
>    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.

Thanks for the history on this.

New Question:

Looking at draft-ietf-mobileip-ipv6-12 section 9.7 page 70,
should the conditions for sending a router advertisement to
a mobile node include some sort of unconditional periodic
retransmission? My concern is the home agent could define
a prefix with a fixed lifetime that the mobile node will treat
as decrementing in realtime. The prefix on the mobile node
could expire without any updates from the home agent. The
retransmission could occur on an hourly or even daily basis,
depending on the Preferred and Valid Lifetimes of the prefixes.

Ken Powell
Compaq Computer Corporation

---

From: "Powell, Ken" <[email-masked]>
Date: Fri, 12 May 2000 11:41:32 -0400

I had a few additional thoughts on my previous questions.

> depending on the Preferred and Valid Lifetimes of the prefixes.

Rather than having the home agent periodically retransmit
the router advertisement, would it be better to say the
mobile node SHOULD send a router solicit to the home agent
when any of it's home addresses' preferred or valid lifetimes
approach expiration? The router solicit could contain:

   Source: Mobile Node's primary care-of address
   Dest: Home Agent's address
   Destination Options w/
     Home Address Option w/
       Home Address: Mobile Node's Home Address
   Authentication header
   Router Solicitation

The Home Agent could respond with a Router Advertisement
as sent in section 9.7 with all address prefixes for the
home network. However, there would be no Binding Request
option needed with the Router Advertisement.

The Binding Request/Update sequence described in section 9.7
is used as an acking mechanism to ensure the mobile node
receives an unsolicited router advertisement. For solicited
router advertisements, RFC 2461 section 6.3.7 says
the mobile node may transmit the router solicitation up to
MAX_RTR_SOLICITATIONS (3) times, each separated by at least
RTR_SOLICITATION_INTERVAL (4) seconds. If no response occurs,
the mobile node could perform home agent address discovery
again.

>       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.

I noticed this was not added to the latest revision of the
Mobile IPv6 spec. It would probably be cleaner to have the
mobile node send a router solicitation with the first binding
update it sends to a new home agent instead. This would
would achieve the same result by triggering the home agent to
send a router advertisement with all known prefixes.

> > => I agree this is useful but I think this is out of the

I think a few restrictions on the process may be
useful. Perhaps something like:

  The method for initializing a mobile node's
  home addresses on power-up or after an extended
  period of being disconnected from the network
  is beyond the scope of this specification.
  Whatever procedure is used, it SHOULD result
  in the mobile node having the same stateless or
  statefull (DHCPv6) home address autoconfiguration
  information it would have if it were attached to
  the home network. Due to the possibility that the
  home network could be renumbered while the mobile
  node is disconnected, the mobile node SHOULD NOT
  rely on storing these addresses locally.

> I tried to understand how a Mobile IPv6 node would
> initialize its addresses on power-up using stateless
> address autoconfiguration when away from home. The
> steps I came up with were:
>
>   <snip>
>
> What information can I expect the mobile node have to
> break this deadlock? Is my reading of how this should
> work way off?

Would it be reasonable for a mobile node to
generate a temporary home address for itself using:

   o the subnet prefix from the home network's mobile
     agent anycast address, and

   o the globally unique interface identifier that
     would have been used to generate the link local
     address if the mobile node were attached directly
     to the home network.

Such a temporary address could be used to establish
a binding with a home agent in the absence of any
other known home addresses. It could be created with
short valid lifetime and a preferred lifetime of zero
to ensure a quick transition to other addresses
generated when stateless or statefull (DHCPv6)
address autoconfiguration runs.

If this were allowed, I can see how a mobile node
could initialize by:

  1) Query DNS for the home network's mobile agent
     anycast address.

  2) Generate a temporary home address as defined above.

  3) Send a Home Agent Address Discovery Request message
     to the home network.

  4) Receive Home Agent Address Discovery Reply message.

  5) Send a binding update option with a router solicit
     to a home agent using the temporary home address.

  6) Receive a binding acknowledgement option with a
     router advertisement from the home agent. This router
     advertisement could indicate to use stateless and/or
     statefull address autoconfiguration. If statefull,
     start the DHCPv6 procedures.

  7) Autoconfigure home addresses according to the prefix
     information options received.

  8) Send binding update option(s) to establish bindings
     for the new home addresses (if needed).

Ken Powell