Subject: Re: Mandating Route Optimization

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

It was the original intent that all IPv6 nodes implement the correspondent 
node side of Mobile IPv6, even if they are not a mobile node.  This was 
considered one of the benefits of IPv6 (i.e., improved Mobile IP).

However as Itojun points out, all current (and soon to ship) product IPv6 
implementations do not include route optimization now because the 
standardization of Mobile iPv6 has taken some time.  [Please note this is 
not a criticism of Mobile IPv6, just observation of the current 
situation.]  It doesn't seem right to make them non-compliant (i.e., make 
RO a MUST).  Perhaps we can come up with some text for a very strong 
SHOULD, or make it a MUST for new IPv6 implementations.

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.

Bob

--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Fri, 31 May 2002 17:31:56 +0700

Date:        Thu, 30 May 2002 16:43:50 -0700
    From:        Bob Hinden <[email-masked]>
    Message-ID:  <[email-masked]>

  | It doesn't seem right to make them non-compliant (i.e., make RO a MUST).

Bob, that's completely bogus as an argument.   I don't know enough about
the issues to comment on the substance, but if RO is something that the
WG feels is important for all nodes to implement, then of course MUST is
the right thing.

Implementations that already exist can't possibly pretend to conform to
a specification that doesn't yet exist, whatever is in that specification.

When the new spec does appear, if older implementations decide that they
want to be compliant with it, then they may need to issue software upgrades,
or something, to get them there.

There's nothing new in this, one day soon I'd hope that we want to make
IPv6 a MUST implement for the Internet (one of the base required standards
like IPb4 is today) - but if the argument is that we can't do that, or lots
of stuff that shipped 20 years ago would become non-conformant, then we'd
never get anywhere.

When we're inventing something new, it is correct and reasonable to
consider what effect that will have on the installed base which knows
nothing about it - and I assume (and hope) that the RO stuff has been
planned in a way such that the world won't break if some node or other
happens not to have implemented it (even assuming it is a MUST).

But we can not, now or ever, allow considerations of existing implementations
conformance state affect the decisions about what new implementations
should be required to implement.

kre

---

From: [email-masked]
Date: Fri, 31 May 2002 19:54:03 +0900

>should be required to implement.

	then we will have two separate set of IPv6 nodes - without mobile-ipv6
	and with mobile-ipv6, and they cannot even ping each other.
	do you feel it acceptable?

	i'm very unhappy about the delay of mobile-ipv6 spec.  it should have
	defined home address option, set it in stone, and then work on other
	things.  implementers cannot support (human resource-wise) drafts
	that drastically change content every time the new version appears.
	even if that technology is a good one, this way that won't deploy.

itojun

---

From: OKABE Nobuo <[email-masked]>
Date: Sat, 01 Jun 2002 00:35:21 +0900 (JST)

From: [email-masked]
Subject: Re: Mandating Route Optimization 
Date: Fri, 31 May 2002 19:54:03 +0900

> 	even if that technology is a good one, this way that won't deploy.

How should we apply the IETF motto, e.g. "rough consensus and running code",
(especially latter words) in this case?                       ^^^^^^^^^^^^

If mip6 people shows experience and validity about route optimization
based upon running code, we will be able to have more productive
discussion.

thanks,

---- nobuo

---

From: Robert Elz <[email-masked]>
Date: Fri, 31 May 2002 22:43:56 +0700

Date:        Fri, 31 May 2002 19:54:03 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	then we will have two separate set of IPv6 nodes - without mobile-ipv6
  | 	and with mobile-ipv6, and they cannot even ping each other.
  | 	do you feel it acceptable?

No, but that means that the way the technical work has been done is
wrong, and it should be fixed so we don't have that problem.  As I said
I wasn't commenting on whether what is being offered technically is
adequate or not, I haven't been paying attention to it at all.

But whether that is correct or not, it certainly can't be the case that
simply changing a MUST to a SHOULD in a doc will fix it.  If there's
a problem like that, it will take a more serious fix.

kre

---

From: Jari Arkko <[email-masked]>
Date: Fri, 31 May 2002 21:51:17 +0300

> a problem like that, it will take a more serious fix.

Just for the record... the current MIPv6 drafts do not have this
problem. A "new" IPv6 node can ping an "old" one and vice versa,
even if the older node doesn't implement RO, HAO, or anything related
to MIPv6. Sure, the communications would be smoother if both parties
used RO and overall the Internet would have to carry less traffic,
but nothing breaks horribly if they don't. This is a change from the
old versions. Also, draft 16 was the first version that we can think
of as being globally deployable for route optimization. This is because
the requirement in the old versions about PKI or pre-configured security
associations would have, in practice, severely limited the use of RO
even if implemented in every node.

In conclusion, we are free to a decision in this WG about what to mandate
for all IPv6 nodes or for new nodes, as far as interoperability goes.
The decision should be based on the technical benefits to the Internet
and the nodes themselves and the meaning of keywords as specified in RFC
2119. And, perhaps I'm naive but I'm actually hoping good features
sell themselves by being useful. I don't buy the argument that CNs
do not care. A CN exists in the Internet because it wants to offer
something, such as a news service. It should want to offer this in
a manner that its clients get the best possible service, including
minimal RTT.

Jari

P.S. John: I believe the current drafts do describe how to use RO.
They even describe how to survive the situation that the peer does
not implement RO. So in this respect I don't think we need anything
new. See e.g. MN state machine 'WaitHC' state and the ICMP action.
Please let us know if something additional is needed. At the moment
I don't see it.

P.S. Mike: Yes, we do need the administrative disable feature on this.
The draft already talks about an automatic disable for situations where
the node is under a DoS attack but a manual disable would be necessary
as well.

---

From: Alain Durand <[email-masked]>
Date: Fri, 31 May 2002 13:31:26 -0700

On Friday, May 31, 2002, at 03:31 AM, Robert Elz wrote:

>     Message-ID:  
> <[email-masked]>
>

When a new technology solves a critical problem for the operation
of the Internet, it make sense to make it a MUST, regardless of
the installed base.

The issues here are to know if:

a) RO solves a critical problem to the operation of the Internet
b) RO is the right approach to the problem.

If I can be convinced of a), b) is another story.
Years ago, the Home Address option was defined and
presented as _the_ thing that will solve _the_ problem.
Then we discovered that there were security concerns,
and a whole new approach, much more complex is now
presented.
How confident are we that this time, this is the right thing?
Has it been tried in large scale environment? Are we
sure it solves enough security concerns that another
version of RO will not come next year to fix it?

As some said early, there are a number of implementations
out there today. It is not that it is not possible to change anything
at this point, it is that there is a need for a certain level of 
confidence
that RO, as defined today, is the right thing and will not change.

	- Alain.

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 31 May 2002 16:50:22 -0400

Here's another reason why RO needs to be optional:

Consider the traffic patterns surrounding a root name server.

Properly functioning clients talk to it at most once every two days
(the current TTL of root server NS records) per TLD used, and do a
single packet exchange per TLD.

There would be no point in it ever maintaining a binding cache.

On the other hand, I don't see much harm in mandating that hosts be
able to politely refuse a binding update request.

						- Bill

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 31 May 2002 14:05:12 -0700

Hello Bill,

There's a big difference between allowing refusal
(which I agree should be possible) and requiring
support in the implementation.

I can make an analogy between your example and
the IPsec mandate.

Your example "works", because there aren't any
communications that last for very many packets.

What if I build a product that ONLY ever supports
insecure applications?  Should I be allowed to claim
IPv6 conformance if my product platform does not
have any IPsec implementation?

Currently, the answer for IPv6 is "no".  But, I
reckon the number of nodes that only ever support
insecure applications would be a lot more than the
number of nodes that only ever support instantaneous,
disconnected application streams.

Plus, one could even devise semi-rational scenarios
where the DNS server needs to support mobility, of course
depending on the applications.  For remote diagnosis,
maybe some (secure!) streaming applications for processed
or graphic data would be highly advantageous, and the
diagnostician might be mobile at the time...
In fact, this doesn't sound at all far fetched to me.

Regards,
Charlie P.