RE: modules of a mh solution (was RE: New multi6 draft: WIMP)

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

> I don't have any particular thoughts about the solution for this.  As
> long as it scales at least as well as DHCP it is fine with me.
>
> The one thing that makes this more challenging than DHCP is the problem
> of timing and initiative.  DHCP is triggered by the client with an
> obvious example being system boot.

DHCP for IPv6 supports server initiated configuration i.e. a push from the
server AFAIK (the reconfigure message from the server)

So what we need now is a mechanism to inform the server on real time about
which prefixes are to be configured in the clients.

Using stateless autoconfiguration, you can use the Router Advertisement in
the same way, so you can inform the hosts which prefixes they have to use at
every moment.

The problem again is how does the router knows about which prefixes to use.

In this case there is an additional problem related to the fact that Router
Advertisement are link scoped, so you need to inform the routers through
other means. A possible option for this would be Router Renumbering
protocol. The problem with this is that AFAIK the router renumbering
protocol is not very supported in available equipment, so i am not sure that
this would be a real option.

the other option for this would be to use DHCP prefix delegation, so you can
delegate a prefix to every router, so that they can announce it through dhcp
to the hosts.

In both cases , stateless and statefull autoconfiguration, the resulting
situation is that you have a central server that manages the prefixes. The
point now is how does this server knows which prefixes are to be announced.

IMHO, the only case that a prefix has to be removed is when the direct link
between the multihomed site and the isp that delegated the prefix is down.

In other failures modes, a prefix should be used to reach a set of
destinations and not to reach others.

For instance a multihomed site with ISPA and ISPB

The link between ISPA and the internet fails.

One may think that PrefixA should be removed and not used anymore.

However, if you do that, you will not be able to reach the other customers
of ISPA

So in this case both prefixes has to be preserved in the site, only that
PrefA should be included in the source address when communicating with other
ISPA customers and PrefB should be used when communicating with all the rest
of the Internet.

That is why IMHO it is so important a mechanism to discover the proper
source address to be used in order to reach a certain destination address.

So according to this, the problem of discovering one's own prefixes would be
simple, you just have to remove the prefix when the direct link with the
provider that delegated the prefix is down. This could be as simple as a
ping or bdf (draft-katz-ward-bfd-01.txt)

The problem is then moved to the source address selection :-)

Regards, marcelo


>
> For multiaddressing, the easy question is how to supply information
> about multiple addresses at system boot.
>
> The harder question is how to get information about the availability of
> new addresses to the client system? Offhand, I think this requires a
> "push" mechanism from the network, rather than a pull mechanism from the
> client, in order to make sure the client learns of the changes in a
> timely fashion.
>
>
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
>