Subject: RE: On the NECESSITY of MIP for LMM (was Re: [Mipshop] WG Last Call comments ...)

From: "Bound, Jim" <[email-masked]>
Date: Thu, 6 Nov 2003 10:49:26 -0500

James,

As implementor HPMIP6 and FMIP6 can easily reuse production code for
MIPv6 shipping today.  Its a no brainer.

/jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of James Kempf
> Sent: Thursday, October 30, 2003 8:29 AM
> To: Soliman Hesham; 'Pekka Nikander'
> Cc: [email-masked]; [email-masked]
> Subject: Re: On the NECESSITY of MIP for LMM (was Re: 
> [Mipshop] WG Last Call comments ...)
> 
> 
> Hesham,
> 
> I don't want to take sides in this debate, but I do have one 
> comment for clarification on your note.
> 
> > There are clear benefits in _reusing_ existing SW though.
> > And many years ago we went through this discussion and
> > the WG decided that it was more beneficial to solve this 
> exercise with 
> > MIP. It sounds like you disagree, right? Frankly, given the current 
> > situation, I think this is a very wise thing to do (reuse MIP). The 
> > benefits of repackaging the same concepts into a different protocol 
> > are very far from being clear.
> >
> 
> If you are speaking here about reusing MIP and HMIP, then I 
> think what you mean is reusing existing designs, not 
> software. To my knowledge (which is probably incomplete) 
> nobody yet has a MIPv6 or HMIPv6 product, and nobody yet has 
> a deployed MIPv6 or HMIPv6 service. Reusing existing software 
> would be something like using DNS or VPNs. There is, of 
> course, experimental software in this area, but the argument 
> for reusing experimental software is less compelling from a 
> business standpoint. There is also a good argument for 
> reusing existing designs, if they adequately satisfy the 
> requirements of a new application, as it enables the new 
> application to more quickly be designed, implemented, and deployed.
> 
>             jak
> 
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Greg Daley <[email-masked]>
Date: Fri, 07 Nov 2003 14:34:13 +1100

Hi Jim,

Just adding the experience of an implementor
who has implemented HMIPv6:

You're right.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Fri, 7 Nov 2003 12:04:08 -0800

Greg,

So you've implemented everything in draft-ietf-mipshop-hmipv6-00.txt and are
satisified that it will work in a production environment? For example, the
MAP discovery option using router renumbering described in Section 7.2?
You've tested this in a large network and know it works?

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "Bound, Jim" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "Soliman Hesham"
<[email-masked]>; "Pekka Nikander" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Thursday, November 06, 2003 7:34 PM
Subject: Re: On the NECESSITY of MIP for LMM (was Re: [Mipshop] WG Last Call
comments ...)

---

From: Greg Daley <[email-masked]>
Date: Mon, 17 Nov 2003 15:14:40 +1100

Hi James,

James Kempf wrote:
> You've tested this in a large network and know it works

I haven't implemented this.
I'd be interested in finding out if anyone else
is planning to do the router renumbering.

I've got the dynamic RA map option propagation
(aka RIP routing) working though.  Whether this
would work in reality is another issue.

Maybe we can define a DHCPv6 option.... :)
It's not like we have to check on every network
whether HMIPv6 is available, if (as you suggested before)
the map discovery can provide information about its
applicability.

DHC wouldn't be the best way to do it, but it may
be better than modifying routers (which you and
other people seem loathe to do).

There are also some issues regarding the SA's in
Linux which may be fixed in 2.6.  Conversations
with some of the USAGI team indicate that they're
not yet doing IKE though, so it may take some time
to implement for Linux HMIPv6.

Whether it's necessary or not to have every piece
of data encrypted with ESP though depends on
how we're treating the interface.  At the moment,
all MIPv6 traffic received will be encrypted to/from
the HA and unencrypted from CN's (by MIPv6).

The (additional) issues are with proof of location/identity
to the MAP, and ensuring that data from the access networks
don't get sent to CN's over the reverse tunnel to the MAP.
If we all agreed on this, then we'd have to work out
another way of bootstrapping the MN-MAP communication,
but that may be half done with the existing ways of
checking the care-of-address (the OCOT test).

Of course, HMIPv6's going to be an experimental
protocol, so it doesn't have to be scalable or
implementable does it? ;)

Maybe we can revisit this stuff if we need to
go to PS later.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Mon, 17 Nov 2003 14:34:36 -0800

Hi Greg,

> the map discovery can provide information about its

If the DHCPv6 option provided information about the access network subnets
covered by the MAP, the MN could recheck again when it reached a subnet on
the border of the coverage area. Through configuration, the DHCP
advertisment could scope the border  so that it was slightly inside the
actual coverage area, to allow some room for fast moving MNs to accomplish
make before break MAP handover.

There is still an issue about how to get a RCoA if this is done, because
presumably that wouldn't be recorded in the DHCP record (too dynamic). This
is part of the bootstrapping problem which the MIP6 group has in its
charter, as the same problem occurs with the HA when the home address is
dynamically assigned.

> other people seem loathe to do).

Well, one of the attractions of HMIP to service providers is that it can be
used with stock IPv6 routers, unlike FMIP, if the discovery mechanism does
not require modifying routers. This makes deployment easier.

> the HA and unencrypted from CN's (by MIPv6).

I'm not sure I understand. I don't believe there is a requirement in the
MIPv6 spec to encrypt all traffic with the HA using ESP, just the signaling
traffic. I assume the same would be the case with HMIPv6. Perhaps I've
missed something, though.

> Maybe we can revisit this stuff if we need to

Yes, these are all appropriate issues for the MOBOPTS RG, where work on FMIP
and HMIP will continue when MIPSHOP completes them.

            jak

---

From: Greg Daley <[email-masked]>
Date: Wed, 19 Nov 2003 10:19:19 +1100

Hi James,

> charter, as the same problem occurs with the HA when the home address is

I think that there wouldn't need to be address assignment,
rather just an information option (so it would be
compatible with the 'O' Flag in the RA).
It would be analogous to the dns relay information
supplied in DHCP, except that it is a routing relay...

A closer look at how todo this could come later,
but since DHCPv6 is standardized, and is likely to
be used for DHCP in the mean time it may be a good
discovery mechanism, in addition to RA advertisements,
which may be valid in some networks.

> not require modifying routers. This makes deployment easier.

Indeed.   Where we draw the line about this is
dependent on a number of factors in practice, but I
think a DHC option can be transferred even without
being understood by the router...

> missed something, though.

I guess you're right about the contents of the
transport from the HA (although in practice, we may
see bulk encrypted transfer to/from the HA if we're
interested in hiding traffic).

The issue is whether we need to establish a security
association using IKE, considering that the
arrangements between the MN and the HA are already in
place (for at least signalling).

> and HMIP will continue when MIPSHOP completes them.

Indeed.

Greg