Subject: Re: Mandating Route Optimization

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 03 Jun 2002 14:37:28 +0900

>>>>> On Thu, 30 May 2002 16:43:50 -0700, 
>>>>> Bob Hinden <[email-masked]> said:

> Independent of how this is resolved, I think the best place to define the 
> route optimization implementation requirements for all IPv6 nodes is in the 
> IPv6 Node Requirements document.  I don't think it should be in the Mobile 
> IPv6 specification because at a minimum implementers not planning to 
> implement Mobile IPv6 might not see it.  There is a design team effort 
> underway to produce an IPv6 Node Requirements draft and I think they should 
> have an -00 version out soon for w.g. review and comments.  This discussion 
> is important input into this document.

I fully agree.  One of the most unfortunate things about the
correspondent node discussion is that it has been discussed only
within the mobileip wg.  It was reasonable when the support of mobile
IP in correspondent nodes was optional.  However, I don't think it
makes sense to decide something is mandatory for all nodes within a
single group that has a very specific goal (mobile IPv6 in this case).
In this sense I think it was an unfortunate thing to make the support
of home address option mandatory in the mobile ipv6 draft.  It should
have been approved by the ipv6 (or ipngwg) wg (I don't remember if it
was though), and should have been documented in a basic specification
of IPv6 once approved.

As for SHOULD vs MUST: as other guys pointed out, it depends on how
the requirement solves a common situation and how the situation is
critical.  Since the MUST affects all IPv6 nodes, the argument for the
MUST basically must convince all IPv6 implementors, including
OS/server vendors, router vendors, and even home appliance vendors.
Additionally, if the requirement is not configurable (i.e. there is no
knob to turn it off), the argument must also convince all IPv6
operators such as ISPs and (possibly) cellular phone companies.

Honestly, the argument for the MUST so far does not seem to me very
convincible - after all, mobile-ip (v4 or v6) nodes only occupy a very
small part in the current Internet.  It may be true that more and more
"nomadic" nodes will come in the near future, where "nomadic" means
the node moves from a link to another link while working, but I'm not
fully convinced that all such "nomadic" nodes are speaking mobile IP.
I'm also not sure how many (correspondent-only) nodes will need to
communicate with mobile-IP nodes in the depicted by mobileip-ers.

Please note, however, that I'm not necessarily making an objection to
mobile-IP (v4 or v6) itself.  I'm just saying the MUST is too strong,
considering the current situation and the uncertainty about the
future.  With the fact that mobile IP is one of possible (though
perhaps likeliest) solutions to support nomadic nodes, I believe it is
better to make effects to other nodes as small as possible in order to
deploy mobile IP itself.  So, I must vote for the SHOULD (or even
MAY).  Even with the MUST, I can imagine that IPv6 stack implementors
who are not convinced will ignore the requirement.  The result will be
a certain amount of "non-compliant" implementations and loss of
interoperability.  Even with the SHOULD, the implementors will
implement the feature if communicating with mobile-IP nodes using the
route optimization becomes attractive enough, while keeping the
minimum interoperability.  I don't just get why we cannot go with this
path.

Lastly, just saying "route optimization is mandatory" does not make
sense to me, because the specication of mobile ipv6 is far from
stabilized.  The current specication may require, say, 1,000 new lines
to implement, which may or may not be a large cost.  But what if it
requires 1,000,000 lines in draft-mobileip-ipv6-99?  Can we still
allow the requirement just because it is the "route optimization"
which is a MUST?  mobileip-ers may want to say that the
standardization will soon be done, but I've been seeing the same
phrase for a few years and cannot be that optimistic (e.g. please do
not forget that the notion of the "return routability" is very new.
how can we be 100% sure that it's stable and will not change?).  Even
if the next revision of the draft passes a wg last call, we'll still
have a review period by the IESG, which is getting longer and longer
nowadays.  So, we can only discuss if it is reasonable to make
"section xx of draft-yy-zz" mandatory for all IPv6 nodes.  This, of
course, does not make sense much, which is another reason why the
SHOULD (or MAY) is better.

In summary:

- if we're going to make something mandatory for all IPv6 nodes, it
  must be discussed in the ipv6 wg.
- (IMO) we cannot go with the MUST, considering the current situation
  and some possible scenarios in the future.  We should delay the
  decision, or should go with a SHOULD or a MAY.
- it does not make sense just to say "the route optimization is
  mandatory."  we should be more specific.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 02 Jun 2002 23:25:06 -0700

Hello folks,

> single group that has a very specific goal (mobile IPv6 in this case).

What I thought is that the mobile-ip group should decide what makes
sense, as far as support for mobility is concerned.  Mandated behavior
for all nodes clearly requires discussion in this group.  We are now
having discussion in this group.  It would not make sense to have the
discussion until the mobile-ip group knew what needed to be done.
And, in fact, the level of specification (MUST or SHOULD) has not
been decided in the mobile-ip group either.  So, this means you are
getting your wish.

> was though), and should have been documented in a basic specification

It never got to the point of going through Last Call, so it was never
quite ready enough to introduce the discussion here.

> operators such as ISPs and (possibly) cellular phone companies.

I think that everyone agrees that the behavior should be configurable,
either dynamically or by administrative configuration.

What do you think about the points I tried to make a few days ago
about general scalability and the likely proportion of future nodes
that will be mobile nodes.

> small part in the current Internet.

Likewise, nodes secured by IPv6 IPsec AH occupy only a small portion
of the Internet.  Do you apply the same argument to convince yourself
that the IPsec mandate was a mistake?

>  It may be true that more and more

A correspondent node CAN be a mobile node or not.  The point is
not to make a difference.  And, you are right that maybe not all such
nomadic nodes will use Mobile IP, but I think there is reasonable
expectation that they will, and results we have so far indicate that the
performance is good and the protocol operates as expected.  This will
be augmented as soon as is reasonable to expect by additional experience
with the return routability protocol.

> minimum interoperability.  I don't just get why we cannot go with this

The reason for mandating the binding management messages, is just
as I have stated it already a few days ago.  It makes a very noticeable
difference in performance when traffic has to be tunneled back and
forth through a home agent in a possibly quite distant network.  This
would be bad for many applications, especially those with various
delay bounds.  Did you look at my previous note on this, or should I
repeat the discussion?

>
> But what if it
> requires 1,000,000 lines in draft-mobileip-ipv6-99?

I'm sure you are kidding.  There won't be any such draft, and
it won't take drastic amounts of code.

> Can we still
> how can we be 100% sure that it's stable and will not change?).

Indeed, return routability is new.  I have myself hoped that we would
be done, and the original expectation is that the IPsec group would
provide something useful for key establishment.  When that did not
happen, we were eventually told that we didn't have the luxury of
waiting for someone else to do it.

Furthermore, if we mandate the return routability tests, and we never
get to Proposed Standard, then I reckon people are not going to be
very motivated to implement the specification.

The point is that if a node is going to support the Mobile IPv6
specification, it has to do the route optimization feature.  If IPv6
nodes don't need to support mobility (contrary to the mandate of the
original IPv6 directorate), then that needs to be laid out.  If IPv6
nodes are going to conform to the original mandate, then this is how
they would do so.  If we screwed up and the Return Routability test
isn't good, then IETF last call is supposed to catch that.  My opinion
is that it is pretty good, and I hope that after looking it over you will
think so too.  For the rest of the policy decisions, I can't add much.

>  Even

According to this logic, all mandates are from now on impossible
for IPv6 nodes.

MAY is a disaster for mobility, at least from the point of view of
Mobile IPv6.

>   must be discussed in the ipv6 wg.

We are having the discussion.

>   decision, or should go with a SHOULD or a MAY.

Even if it's mandated, I doubt we would see interoperability tests before
next year, and then implementation in products not before end of 2003.
How much longer shall we delay?

>   mandatory."  we should be more specific.

Specifically, Return Routability messages (HoTI, CoTI, HoT, CoT),
Home Address Option, and Binding Update.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 3 Jun 2002 08:47:21 -0700 (PDT)

JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= writes:

 [eminently reasonable assessment of why SHOULD is
  more appropriate]

 I'd add tht MUST is primarily a tool for insuring
 that different implementations will interoperate.
 Route optimization doesn't meet that criteria since
 it is, after all, an optimization. If it's a MUST,
 it would be for, essentially, global policy reasons
 (death of net, film at 11...). I don't think we have
 enough information to really make that kind of 
 pronouncement though. MIP isn't the only one creating
 dog-leg routing on the net these days: VPN's do the
 same thing. Indeed, VPN+MIP seems like it would be
 a fairly common deployment scenario. Does route
 optimization even buy you anything in that case?
 
		Mike

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 04 Jun 2002 03:24:49 +0900

Hello, thanks for the prompt and detailed response.

>>>>> On Sun, 02 Jun 2002 23:25:06 -0700, 
>>>>> Charlie Perkins <[email-masked]> said:

> been decided in the mobile-ip group either.  So, this means you are

Okay.  I really hope this rule will be kept in future discussions.
(Of course, proposal related to mobile-ip will typically come from the
mobileip wg, including the ones that affect all nodes.)

Okay.  I was actually concerned about arguments like:

>>>>> On Wed, 22 May 2002 08:53:08 -0700, 
>>>>> "Charles E. Perkins" <[email-masked]> said:

> That is under discussion.  In fact, I strongly believe that EVERY
> IPv6 correspondent node MUST implement return routability procedures.
> Furthermore, every IPv6 node already MUST implement Home Address Option.

I understood this was a personal opinion, but I read this to mean that
1. the decision about Home Address Option was already done.  it's a
   MUST.
2. now that Home Address Option is a MUST, it should be quite natural
   to mandate return routability (or the entire function of route
   optimization) as well.

(though I may have misunderstood the nuance in the first place) if
this kind of logic is justified, we'll be able to make arbitrary
extensions that affect all nodes by a proposal in a draft written and
discussed within a particular group.  I was afraid about this stroy.

But, I'm okay if the ipv6 wg (in this case) will discuss if an
extension mandating something to all nodes is acceptable, and the wg
can even start with rejecting former proposals which are MUST.
(here I'm just talking about the general procedure, rather than the
particular issue of Home Address Option).

> either dynamically or by administrative configuration.

Okay.

> that will be mobile nodes.

I respect your insight, but my honest feeling is that it was a guess.
We do not have actual results about the delay when communicating
without route optimization.  We're (or I am) not sure about the real
rate of nomadic nodes *speaking mobile-ip* in the future Internet.
IMO, requiring a MUST (for all nodes) due to a performance issue needs
a concrete evidence like results of performance tests, not a guess.

We can say that a SHOULD means every implementation can be compliant
without supporting route optimization at the cost of efficiency in
mobile-ip environments.  However, we can also say that a MUST means
any implementation can be faulted not to be compliant even if the
implementation was not expected to make frequent communication with
mobile-ip nodes and wanted to omit route optimization due to (e.g.)
very limited resources.

I recall the discussion about "minimum requirements" for low-cost
appliances or for 3G devices.  The authors of the drafts proposed to
omit some features which are mandated in existing RFCs, due to limited
resources and usages.  The result of the discussion was "we cannot
allow such non-compliant implementations that easily".  Once we
mandate route optimization, the same situation may happen in the
future.

Since such low-cost devices will also be in a large part of the future
Internet (v6) (though some of such low-cost devices can act as a
frequent correspondent nodes), I don't think it a good idea to add
another restriction at this early stage.  In theory, we can change
requirements described in RFCs if we find them inappropriate in the
future.  However, the recent discussion about the low-cost devices
shows it will be very hard in practice.

> that the IPsec mandate was a mistake?

No, because in this case it's an all-or-nothing choice; if we do not
implement IPsec, we cannot be secure (at least at the IP level).  On
the other hand, even if we do not implement the route optimization, we
can still communicate with mobile nodes in some less-efficient manner.
Of course, one can say that the mobility case is also an
all-or-nothing choice, i.e. that "the less-efficient manner" means not
working.  But, at least to me, the latter argument is not as clear as
the former - again, we do not have concrete results about the
performance.

Going back to the route optimization issue, I don't just get why we
cannot go with a SHOULD.  Some implementors have already said that
they will implement the feature (even with a SHOULD).  So, we'll at
least have an environment to test the effectiveness, interoperability,
performance (and whatever necessary) of the optimization to make a

> next year, and then implementation in products not before end of 2003.

then I think we can wait for results of the experiments, rather than
to make a strong requirement for all nodes at this stage.

(I won't make responses to other parts of your reply, because they
would almost be a repeat of the points above.  If you feel it unfair,
please point it out).

Thanks,

					JINMEI, Tatuya

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 03 Jun 2002 12:49:35 -0700

Hello again,

> particular issue of Home Address Option).

I reckon that before IETF last call on any universal IPv6 mandate,
the mobile-ip working group will have the responsibility to make
the reasons for the mandate clear.

> I respect your insight, but my honest feeling is that it was a guess.

It's not a guess that reverse tunneling lengthens the response time
for packets sent from a mobile node.  That's just arithmetic.

In my previous note, I clearly labeled the facts and opinions.
Did you dispute the points I listed as facts?  Did you dispute
the points I labeled as opinions?

> without route optimization.

This, again, is arithmetic.  Plus, there have been publications
carrying out the arithmetic and simulations, albeit from IPv4
route optimization.  The difference between IPv4 and IPv6 does
not matter here.

>                            We're (or I am) not sure about the real

I'd be very interested to hear how you can resolve the following
problem:
- If we do NOT mandate the required feature, and a lot of millions
  of mobile nodes implement Mobile IPv6, then there will be a lot
  of millions of IPv6 nodes built between now and then that will not
  work well.
- If we DO mandate the required feature, and Mobile IPv6 is a flop,
  then there will be a lot (but probably somewhat fewer than above)
  nodes that   "unnecessarily" implement the feature(s).
- If we mandate the feature LATER, then in the meantime and for
  a year afterwards, many of the devices manufactured to be compliant
  with IPv6 specifications (that is, _many more_ than we have now)
  will suddenly become noncompliant.

The intended effect is to reduce the long-term pain of noncompliance.
If we settle on SHOULD, then I think that we should also agree to
periodically re-evaluate the evolution of mobile networking in the
IPv6 Internet, and also to make it clear to manufacturers of all
IPv6 devices that noncompliance entails peformance penalties for
all communications with mobile devices (that implement Mobile IPv6).
A manufacturer that fully understands the trade-offs, and believes
that the applications running on their device do not have any special
needs for faster performance for streams to/from mobile devices,
would then take the option to streamline their implementation.
This would be reasonable.  The approach of interpreting SHOULD as
a license to speed up product introduction is the problem I am
mostly worried about, and many people express concern that SHOULD
is taken with the unfortunate meaning instead of the literal meaning
from RFC 2119.

> mandate route optimization, the same situation may happen in the

I thought the discussion about "minimum requirements" was pretty
good!  In fact, it's just the kind of discussion that was needed,
as shown by recent conclusions about NUD.  I also think that similar
analysis is needed by vendors before they decide whether or not to
implement the route optimization features.

> shows it will be very hard in practice.

It is important to keep IPv6 implementable for low-cost devices.
This has been a driving force behind the design of HoTI, CoTI, HoT,
and CoT, as well as HoA.  These are expressly intended to be light-weight
signals.  I feel that you are making the discussion in the abstract,
instead of determining exactly how much harder it is to do the
route optimization messaging.  Furthermore, the analysis should be
taken with respect to the _incremental_ cost, once IPsec has already
been implemented.

>>   ...   nodes secured by IPv6 IPsec AH occupy only a small portion
> implement IPsec, we cannot be secure (at least at the IP level).

Actually, I think it's exactly the same from THIS argument.  A node that
does not implement IPsec, cannot run secure applications.  A node that
does not implement route optimization, is far less likely to be able
to meet delay bounds, and also will experience some (perhaps quite
significant) loss of robustness in communications.

> On the other hand, even if we do not implement the route optimization, we

No, it is just as you have described it.  But, for some applications,
performance matters.  You wouldn't watch a TV show with insufficient
bandwidth to your device, I'm sure.  You wouldn't use a handset for
voice applications if handover performance stunk.  To be precise,
mandating route optimization will enlarge the realm of applicability
for deployment of applications on IPv6 mobile devices.  Not doing so
means you'll have to find other protocols to run those applications.
Full employment!

Regards,
Charlie P.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 04 Jun 2002 13:18:14 +0900

>>>>> On Mon, 03 Jun 2002 12:49:35 -0700, 

> for packets sent from a mobile node.  That's just arithmetic.

Perhaps I was not very correct about the wording.  It's true that
reverse tunneling lengthens the response time.  But it's not sure
about how long the response time takes.  It's not sure how it is
serious for typical applications using mobile-ip.  It's not sure about
how many correspondent nodes will actually lengthen the response time
in practical operations if we make the requirement a SHOULD...

> the points I labeled as opinions?

I did not necessarily to dispute your facts and opinions.  They may be
true or false.  I could just not be sure.  I admit this argument is
not fair in general, because I did not provide concrete (negative)
evidence either.  However, in this case those who are trying to
mandate something are responsible for giving concrete evidence.

>   of millions of IPv6 nodes built between now and then that will not

if a lot of millions of mobile nodes implement Mobile IPv6 and a lot
of millions of correspondent nodes do not implement the optimization
(due to a SHOULD) and not implementing the optimization is really
critical, then it can be a problem.  I'm just saying we're not (yet)
sure about all the conditions at this stage.

>   nodes that "unnecessarily" implement the feature(s).

And the cost of the devices will unnecessarily be raised, the ship
timing will unnecessarily be delayed.  Not mandating the feature (at
this moment) can solve the situation.

>   will suddenly become noncompliant.

Yes, but as some other guys pointed out, we cannot always avoid the
situation that makes some older implementations non-compliant.
Additionally, if we decide mandating the feature LATER, then we'll
have found very convincing evidence (with some concrete results)
before that point.  During the procedure, some implementors may find
the merit of supporting the optimization and implement it.  So, not
all implementations that choose skipping the optimization now will
"suddenly" be non-compliant.

> next year, and then implementation in products not before end of 2003.

I don't get why we cannot live with the gradually deployment.

Please let me rephrase my opinion again:

>>>>> On Tue, 04 Jun 2002 03:24:49 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> further decision.

(snip)

> implement the route optimization features.

I agree, but I don't think we have enough evidence for vendors to
decide whether or not to implement the route optimization.  Thus, I'd
like to let the vendors to make the decision after we collect enough
(concrete) information, rather than to mandate the feature at this
moment.

===

I believe I've fully dumped my opinions and understood yours.  Those
two are so opposite, and I'm not sure if we can reach a consensus by
further discussions.  So I'd like to hear other implementors for now.
After all, if all (or overwhelmingly majority of) related vendors are
convinced to mandate the route optimization (I doubt that though), the
discussion will just be over.  (Of course, please feel free to make
comments to this message.)

Regards,

					JINMEI, Tatuya

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 4 Jun 2002 13:32:35 +0100

>   mandatory."  we should be more specific.

My take is that this should be a SHOULD.

I actually think that it depends upon the type of device,  and how it
is expected to be used.

So I'd say in general,  RO is not generally needed when a router
(non mobile router) is the CN,  for some really minimal implementation
(i.e. IP stack in a fridge,  light switch etc) there's no need whatsoever,
but for other general nodes - my computers,  mobile phone etc,  then RO
should be implemented.  Given that and a differentiation on device
basis,  I say:

for routers => SHOULD
for minimal nodes => MAY
for other nodes => MUST

As to what's being done;  as others have pointed out there is already
shipping code which doesn't implement RO (as defined in draft-17) thus
we already effectivly have a MAY situation.

After glancing through draft-17 recently I decided that (for a router)
one didn't need to bother with implementing RO initially (if ever).

That was based upon the assumption that traffic directed to/from the
router itself would generally (or almost always) be from within the
organisation owning the router,  and as such dog leg forwarding would
be uncommon.  Obviously ICMPs generated by the router are a possible
exception.

Hence the view that we could leave implementing RO for CN functionality
within a router until some later stage,  i.e. ship product without it
(as happens now) and then implement the functionality within some later
release of software.

Now if this was a router that was also acting as a HA,  the analysis
would be somewhat different.

DF