Subject: Re: [mobile-ip] MIPv6 IPSEc and s=0

From: Marc Hasson <[email-masked]>
Date: Tue, 14 Jan 2003 15:06:36 -0800 (PST)

Hi Charlie,

 > Having multiple subnets is part of the IPv6 architecture, and
 > the means to support them effectively has been part of the
 > Mobile IPv6 specification for a long time.  The work has already
 > been done, in _preparation_ for deployment in production
 > networks.  If you don't think that having multiple subnets is
 > very important, then that seems to be something to be worked
 > out in the IPv6 working group.  Until then, and considering
 > that we've got a workable answer for now, I hope we can
 > use what we already have and close this issue.  And get the
 > specification published!

I'm sympathetic to what you say above but I will remain a doubter of
the benefits of S=0's complexities until I hear example scenarios that
convince me otherwise.  Its still an optimization that is causing a lot
of discussion and the benefits are still questionable IMHO.  Its ironic
to me that several hours after this note of yours we were "treated" to
the following comment on a new thread (that I haven't really read
yet):

     Great, another issue with S=0 involved...

Good thing you mentioned "workable answer for now"!  :-)

Forced S=1 can "effectively" support multiple home network prefixes,
IMHO, but it does take more binding messages back home for each new
care-of-address change.

Offhand I can think of 2 main reasons why there'd be multiple
globally-routable prefixes on a production home network that a MN may
wish to obtain addresses from.  These 2 are: Address transition
renumbering and a provider multi-homing situation where the home
network wanted additional connectivity reliability.  IPv6's "multiple
subnets" also conveniently allows for other subnets, such as
site-locals, but thanks to the latest pre-20 draft those are not under
consideration here since a home address or care of address SHOULD NOT
be a site-local address.

I hope we can agree that there is no need to optimize the address
transition renumbering case with S=0 (but the issues don't change any
even if we don't agree on this).  So that leaves us with only the
multi-home case, or some other scenario I haven't thought of that home
networks will require.

So, what are we talking about here for the most-relevant case of an
already-reigstered MN moving to new COAs and having to redo its home
bindings?  First, I would assume we are talking about rebinding
something like 2-3 addresses and not 50-100+.  If there's a realistic
scenario for the later, you'll convince me for S=0.  If we're just
trying to make something "engineering perfect" for that possibility,
don't bother trying to convince me.  There doesn't appear to me to be a
latency issue with the 2-3 since multiple S=1 bindings may be emitted
by the MN in parallel.  The additional MH packet processing itself
would add a latency thats in the noise.  So that leaves us with the
packet load itself.  Well, I read it as 2 smallish messages (BU/BA) per
additional address to renew a home registration binding and if thats
too much of a strain while the MN is also trying to do "real work"
while updating all its CNs then lets forget all of this effort (MIPv6!).
In whats likely to be a common case, 1 home address, S=0 buys
nothing.

For now, I'm fine on agreeing to disagree since I don't see the need
for the S=0 optimization but some others seem to.  I will continue to
implement it, as I did in its first -15 version, if it stays in the
spec as it seems it will.  But in my opinion its pretty clear that the
protocol will be more robust and testable without the S=0 optimization
than with it.

   -- Marc --

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 15 Jan 2003 09:44:40 -0800

Hllo Marc and others,

I am distressed to see the discussion of removal of
this feature.  I would ask that you reconsider.
After a short discussion, I have a proposal I hope
you would find attractive.

My main concern is that such a decision goes a long
way towards making mobile nodes into "second-class
citizens".  My goal has been to avoid this.  Each and
every decision by which the home agent fails to effectively
represent the mobile node on the home network contributes
to this bad effect.

Any systems that depend on use of multiple prefixes should
then start to include code to check whether or not the
platform was mobile.  This sort of special-case analysis
makes life miserable for engineers, and particularly so
when the effects of mobility are often subtle and hard to
account for.  My goal for Mobile IPv6 was to avoid this
sort of case analysis requirement.

I believe that taking this feature out of the specification
will lead to complex interactions in the future that far
outweigh the questions that have been raised now.  In other
words, removal amounts to a small (microscopic) bit of relief
now, at the cost of a potentially huge headache (or even
amputation) in the future.  Sort-of like environmental policy
nowadays (oh, I didn't say that, please insert backspaces...).

We already have a workable solution, so there is almost no
benefit of removing this feature.  It's been tested, and
is known to work.  It would be different we didn't have a
good answer, but we do and so we should keep it.

I think it is a big mistake for actions in the Mobile IP
group to effectively redefine IPv6 features, by causing them
to suddenly become nonscalable.  I don't want to see the
result that IPv6 programmers have stories about how their
programs die as soon as the platforms go mobile.  We have
avoided that to a great extent.  Making multiple subnets
unscalable represents a huge retreat from a valuable goal.
It represents action by the mobile-ip group that effectively
creates new IPv6 architectural limitations, for no known
good reason.

My proposal: Keep things as they are.  Publish the specification
             as Proposed Standard.  Raise the issue about utility
             of multiple subnet prefixes in the IPv6 working group.
             When we get answers there, raise the issue here again.

It will be much harder to do it the backwards way of
removing and then reinsertion.  For proof, look at the
difficulty of managing updates to other specifications!

Regards,
Charlie P.

PS. I hope it has not gotten to the point where "optimization"
    and "improved performance" and "IPv6 compatibility"
    and "scalability" are dirty words.

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 15 Jan 2003 12:01:59 -0800

Charlie -

I see your point, that the HA should be as much as possible a true proxy for
the MN when the MN is not at home, but as a MN implementor, I'm not in
complete agreement.

As I understand it, the main benefit of MIPv6 is for the MN to have an
unchanging global scope IPv6 address, where it can be reached at by services
running on the network (for example, VoIP) regardless of its current point
of attachment to the Internet. A MN really only needs one of these, IMHO.
This enables push technologies where the network initiates the connection to
the user. A secondary benefit of MIPv6 is for existing socket connections
established by the MN on the home network to survive movement. If the MN is
using its registered HoA as the source address of these connections, then
that will be the case. However, many types of Internet access (such as web
browsing) result in short-term connections, and these types of
communications can just as easily use a temporary address on the foreign
link such as a CoA rather than the registered HoA.

And, there actually is a benefit to removing the S=0 feature (which,
essentially means to remove the S bit) - it reduces the complexity of the
base MIPv6 specification, and makes it easier for implementors to implement.
The MIPv6 base specification is already pretty long.

W/ regards to the HA proxying for the MN's auto-configured link-local scope
address (which we aren't really debating here, but it is part of the HA
proxying for MN functionality), I have never considered that to be a great
feature. Now that there is the potential for the HA to forward some of the
MN's link-local scope traffic using the HA-to-MN tunnel, it seems like it is
needed, but for MLD it isn't (it is just as easy, and probably more
efficient for the MN to join application-level multicast groups on the
foreign network, rather than doing it over the HA-to-MN tunnel). Perhaps L=1
is more necessary to support DHCPv6...

Anyways, just my 2 cents.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Charles E.
> Perkins
> Sent: Wednesday, January 15, 2003 9:45 AM
> To: Marc Hasson
> Cc: [email-masked]
> Subject: Re: [mobile-ip] MIPv6 IPSEc and s=0
>
>
> Hllo Marc and others,
>