Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed & sufficient (but has consequences)

From: "Jari T. Malinen" <[email-masked]>
Date: Fri, 01 Mar 2002 01:52:05 -0800

Pekka,

I believe my point did not come clear from earlier mails.
I changed the topic to match the discussion.

The host identity duality with legacy is more involved than
meets the eye. At end of your first mail you seem to indicate
it would not be needed and multi-homing would solve the
other cases (MN risks it offering RR). These are valid
scenarios _when_ one can do that but in some cases one
cannot avoid needing to deal with knowing the duality.

My main point was that if this is the case, there is more
need for change than just the bit encoding itself. Blind
multihoming is not enough. DNS is a case. Legacy services
resolving to one address are in many places; mere multihoming
for the webserver case may call for either duplicating the
service or changing DNS to be bit-aware. In DNS you recognized
the issue, but I am afraid this is not the only place the
issue causes changes. URLs may have addresses, some
other protocols map identities to addresses besides DNS
or transfer these identities so that some content becomes
non-interoperable with legacy nodes.

> IMHO, if the MN's name maps only to one address that doesn't
> allow RR, then that is a choice made by the MN.  It does not
> want to use RR.  No more need to discuss here.  :-)

This note seems to indicate I did not manage to describe
the core issue. If the legacy support is a non-goal then what
you say here is fine. But it's not always just for the
MN to decide. Identity encoding itself, such as the bit method,
causes its own legacy worries that one may not just ignore.
Any time identity encoding or management provides one address
only or blindly, it is a problem (more later).

> > Consider MN runs a web server and its DNS name is encoded, say,
> > into icon URLs on its homepage. If this name maps to the address
> > allowing X, MN would need a separate homepage encoding another
> > DNS name for RR address to serve the legacy node with RO. And so
> 
> Why the MN's DNS name can't map into multiple addresses, provided
> that it wants to support both RR-based and non-RR based RO?
> AFAIK, several addresses is perfectly valid practise already today.
> If the CN uses DNS to resolve the addresses, it anyway needs
> to select which address to use.  I think Richard Draves is
> working on the I-Ds discussing address selection, or maybe that
> is already an RFC, I don't remember.
> 
> Thus, if the one-bit method is accepted, the address selection
> I-D/RFC must be updated.  Or we need a new one explaining
> the choices a "new" CN has to make.  Good new point.  :-)

Here it seems some of my point was understood, but the
problem is a bit deeper than DNS, which was only an example.
Any protocol which maps to some identity to one IP address
or one address at a time, or blindly hands out IP address for
home address use may need an update. These include stateful
autoconfiguration and other managed address allocations where
managing entity needs to know if MN supports a non-RR method
if it hands out addresses for new and old MNs.

E.g., assume a legacy MN gets its HoA from a home link
DHCP, or some managed link or layer, the address given to MN
may be useless unless it supports the new method. A temporary
HA should in a scalable way ask if MN only knows RR before
handing out a potentially useless HoA.

> > on, for different services mapping or passing single addresses
> > to CNs. Here, since applications 'hard-code' single identity
> > for MN, RO using RR with MN does not work at all with _any_ node
> > after the moment MN changes its identity to the new one
> > requiring X. This even though MN would have another identity
> > for RR, e.g., to be able to do RO with legacy nodes, or by a
> > policy, e.g., use RR with nodes inside its firewall-protected
> > domain.
> 
> I still don't understand this "single address" business at all.
> To me it has been clear for quite some time that in the IPv6
> world the hosts will have multiple addresses, and it is perfectly
> legal that a host thinks to be communicating with multiple peers
> even though, in reality, it is talking to a single one.

Multihoming is not the issue. It is more of an application
behavior consequence that multiple identities are not necessarily
independent especially when we talk about legacy interoperation
of existing and new applications.

> > If MN falls back to RR, either the above effect happens with
> > applications, or there needs to be some 'configuration' or
> > implicit rule that maps the new identity to MN's RR-identity for
> > legacy nodes (CN switches the addresses transparently) for these
> > legacy CNs to be able to do RR with the X-address MN when using
> > those applications.
> 
> I am sorry, but the text above does not make any sense to me.
> I just don't understand how you are thinking.

The above was an attempt to speculate how a legacy scheme
in CN might work "transparently" (no change to applications)
when using the bit method.
By the ability of doing a transparent mapping of X HoA to
RR HoA in the same node by some implicit rule, whereby a
legacy node could try another address if the primary is a
forbidden one. But it is clumsy, and that was a point here..

> > I hope the bidding down issue could be closed soon. However, the
> > above concern motivates that at least an alternative (static
> > config) would be there and that possible limitations of the
> > 1-bit are understood and recorded, well enough to explain
> > how it really works for legacy support.
> 
> I sure hope that the bidding down issue is closed soon, too.
> 
> Now, would you Jari, in turn, explain how you think that
> static configuration could be made to scale to internet
> wide operations where MNs connect to CNs, and the CNs do not
> know the MNs a priori?

Good that you brought this up. Scaling to the global network
in a general case by static configurations obviously is not
doable so that CNs know all different HoAs. Static configuration
can be an interface to future methods. Also, switching RR
off statically scales better if it means e.g. that no HoAs are
served with RR, or HoAs with CoA prefix only in certain networks
(e.g., in local protected domain) are served in some cases.

Note the difference to the address encoding case: there MN lets
CN know what it wants; in a static configuration MN or CN
can locally decide they don't trust RR, with no
identity duality problem. But configuration choices are
more limited. But, that would amount to less attempt to support
legacy (avoiding new legacy problems in the process). So it is a
tradeoff. Static configuration could be seen as a backup choice
should the bit method cause to be too problematic.

> --Pekka

BR,

-Jari M