Subject: RE: [mobile-ip] Routing header Vs tunneling

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Mon, 10 Dec 2001 21:44:31 -0600

>Agree. This might put me on Glenn Morrow's FUD list, but here's an
>extreme position:
>

Extreme indeed :)

>I think this is where the IESG must step in. Yes, the MIP wg can go
continue
>using RH/HAO, but I think it has been successfully demonstrated that
>tunneling with the zill/deering extensions can accomplish the same
thing.
>It is the IESG's job to avoid proliferation of duplicate mechanisms.
Better
>one well-known mechanism than a slew of them. Definitely true for
>security and firewalls point of view, so it can be couched in those
>terms.

MIPv6 has been worked on for over five years now. The proposal to drop
RH/HAO is equivalent to going back to square one and starting to
redesign the IP mobility protocol. I think the IESG would be moving
the yardstick on IP mobility a few years back if we decide to take
this approach. If you want the perfect solution for IP mobility, then
we may as well wait for a few more years and wish that an even better
solution for moving packets between MNs and CNs comes up. Or we could
take the current solution with the RH/HAO to completion and see if we
can have a working solution today. 

If you really want to redesign IP mobility, there is nothing to stop
you from doing so. But I do not believe it has to be at the cost of
stopping the MIPv6 work in its tracks. I think we have spent more than
enough time on trying to solve this problem. We have a few solutions
that will fix the problem. Lets get this done now and then maybe go
back to thinking better ways of doing tunnelling and mobility.

>
>Notice that this nearly happened in IPv4 with Dave Johnson's minimal
>encapsulation (rfc2004) but it didn't gain much ground cuz only the
>MIP wg was pushing it. This new zill/deering option is now outside
>the MIP wg, where it should be. MIP wg should just adopt it, help
>spec it, push to put it on the fast-track and get it done. 
>

And spend the next few years without a solution for IPv6 mobility? I
would not even consider this as an option for MIP WG to consider at
this time.

>And yes, we should deprecate RH/HAO. Anything to make mobility less
>'weird' and more in line with non-mobile wg's (IPv6) will save us
>problems down the road. 

Maybe while the IESG is thinking of deprecating the RH and DO headers,
they could consider a few others as well :( Sorry if this sounds so
negative, but we seem to be digging a deeper hole to get ourselves
into. 

>asbestos shields on,
>-gabriel

-Basavaraj

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Dec 2001 20:16:07 -0800

Raj,

I agree with your position. We need to get MIPv6 to RFC yesterday,
so that we can start the process of productization and deployment
in earnest.

The place for research work on next-generation mobility protocols is the
IRTF Micromobility Routing group.

            jak

---

From: TJ Kniveton <[email-masked]>
Date: Mon, 10 Dec 2001 20:52:27 -0800

> IRTF Micromobility Routing group.

Good point, James. I would add that if effort is applied and MIPv6 gets to
RFC soon, it seems a lot of resources would be freed up to work on other
mobility challenges, including a next-generation solution with all of the
good ideas generated thus far.

However, if energy is applied to getting those ideas into the current
solution, no progress will be made on either goal.

-TJ

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Dec 2001 06:04:26 +0100 (CET)

> good ideas generated thus far.

Do you think that the HAOpt+RH vs. tunneling is something that an updated
MIPv6 protocol would do differently? Or were you considering other ideas?

Assuming they are semantically equivalent (i.e. solve the same security
requirements etc) then changing from using one encoding to the other wouldn't
solve any new problem and wouldn't add any capabilities.
But it would require implementations to be capable of interoperating with
both the old and the new encoding.

This isn't an argument that the right thing is to switch to do tunneling;
but it is an argument that this is a "now or never" decision.

  Erik

---

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 10 Dec 2001 22:32:38 -0800

> MIPv6 protocol would do differently? Or were you considering other ideas?

Route optimization and security are a really interesting topic of study,
and I'm sure that some time down the road, we could look back at how
well HAO+RH has worked in the Mobile IPv6 v.RFC deployments, perhaps try
out the tunneling idea in some implementations as well and do interop
testing as has been done with HAO+RH, and maybe weigh that with some new
ideas, to come up with some really good extensions / implementation
Info-RFCs, Mobile-IPv6 v.2, or whatever..

> both the old and the new encoding.

Yes, this is true. And to some extent I imagine that it would be true of
the current situation as well: Mobile IPv6 implementations use what has
been specified since day 1. And OK, let's say that's not such a big
deal, we can with some fixed amount of work, go and change all of these
implementations to use something entirely different. It's also my
understanding that all IPv6 nodes (CNs) are supposed to implement HAOs,
and I would imagine the amount of work to go change all of these
implementations and deployments might be very large, and that trying to
do so might end up crippling any chance of widescale Mobile IPv6
acceptance on the Internet.

> but it is an argument that this is a "now or never" decision.

OK, I guess my response would be that it is a "justify or never"
decision. Since we're past the design phase, unless an overwhelming
reason to change
an existing mechanism can be clearly justified and defended, there is no
reason to do it.

-- 
        T.J. Kniveton 
  Communications Systems Lab
     Nokia Research Center

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Dec 2001 07:46:42 -0800

Erik,

Arguably, deployment of MIPv4 was hindered by the fact that it was
developed long after IPv4 was deployed. With
MIPv6, we have the opportunity to correct this situation. IPv6 may be a
curiosity in the US, primarily of interest
for toasters and refrigerators, but in China and Japan, it is a vital
part of providing people with basic Internet
service. The Japanese government has started giving tax relief to ISPs
that offer IPv6 service, for example. Since most people in China and
Japan are looking for mobile Internet service, getting MIPv6 to proposed
standard is crucial in speeding deployment of basic Internet service in
Asia.

If we start discussing using tunneling instead of header options for
MIPv6, we are looking at a minimum 3 year
delay before MIPv6 is ready for serious product implementation and
widespread deployment. Considering
the 9 month delay that the BU security problem has thrown into MIPv6,
I'd estimate 6 months to a year to
weigh requirements and decide among competing proposals, 6 months to a
year to get prototype implementations
ready and do interoperability testing, and 6 months to a year for the WG
to finish up loose ends and the IESG
to weigh and approve the result. This is simply unacceptable.

IMHO, unless it is impossible to provide the required level of security
with the existing design, we should fix the security problems and get
MIPv6 to proposed standard as soon as possible, so non-US wireless ISPs
have an opportunity to start deployment. Otherwise, they are going to
start seriously looking at GPRS integration with wireless LAN and other
non-IP based solutions that are here today. Meanwhile, we should start
working on next generation micromobility routing in the IRTF, with the
goal of having a solution ready for the IETF within 3 to 5 years.

                jak

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Dec 2001 17:14:08 +0100 (CET)

> Info-RFCs, Mobile-IPv6 v.2, or whatever..

With a potential MIPV6.2 using tunneling would you obsolete MIPV6.1
(using HAOpt/RH)? Or require that everybody implement both?

> acceptance on the Internet.

The CNs that implement HAOpts today are unlikely to satisfy the security 
requirements around those options since the draft has said it is ok to accept
HAOpt without any checks.
Thus all those CNs need to be updated in any case.
(In the interest of full disclosure I did implement HAOpt processing in
Solaris 8 per the I-D at the time.)

> an existing mechanism can be clearly justified and defended, there is no

I agree that the pronents for making the change need to make the arguments.
I do observe that such suggestions were made to the MIP mailing list
about 2 years ago which met utter silence.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Dec 2001 19:32:13 +0100 (CET)

> widespread deployment.

Can you quantify where the additional 3 years would come from?
(Or is this a total number taking into account solving the BU
security issue?)

> Considering

For BU security?
Or if the WG decides to use tunneling instead of HAOpt/RH?

  Erik

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Dec 2001 14:50:23 -0800

> (Or is this a total number taking into account solving the BU

See below. These are rough and somewhat subjective estimates,
based on my observation of the time it requires for major
feature changes in protocols.

> Or if the WG decides to use tunneling instead of HAOpt/RH?

Specifically for using tunneling instead of HAOpt/RH. I think BU
security
could be wrapped up by the end of next year, if the IESG fast tracks
the security review and implementors come back sometime next
year with a clean bill of health as far as interoperability is
concerned.
I think it will take much longer to work thorough the implications
of  replacing HAOpt/RH with tunneling.

            jak