Subject: [Mipshop] RE: R bit and DHCP

From: Soliman Hesham <[email-masked]>
Date: Mon, 24 Nov 2003 10:46:43 -0500

> > having the MAP option in the RA makes this process very quick
 > > (compared to other methods) because the RA tells the MN whether
 > > it moved (which is needed, with or without HMIPv6) and at
 > > the same time it tells the MN whether it's still in the 
 > > same MAP domain.
 > 
 > Those are advantages. Disadvantages as compared to dhcp is 
 > that one must
 > modify the routers. I'm just agreeing with others that this 
 > is an alternative.
 > Not sure if we should work on it now or leave it for later 
 > (mobopts?).

=> There is a number of alternatives that were discussed
sometime ago for MAP discovery. For example: Multicast, 
DHCP and DNS. It would be interesting to see the pros and
cons of each in a proper study. This could be a specific
topic for Mobopts. I agree that there is a price with the 
current mechanism (updating ARs) but I don't see it as a major
thing because naturally all these choices will come down
to tradeoffs between performance, fast recovery from 
MAP failures and ease of deployment. The "ease of deployment"
part is a bit hard to quantify. But it looks like a good
investigation is needed to assess those tradeoffs. Mobopts
could be one place to do it, unless we want to add it to
this charter. 

Hesham

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

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Nov 2003 21:32:34 +0100

> could be one place to do it, unless we want to add it to

I wouldn't advocate including it mipshop's charter. I'd rather do it in
MOBOPTS. Not sure if a short mention of this possibility (not a
full solution, though) is in order. What do others think?

-gabriel

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Nov 2003 21:47:51 +0100

[rather minor...]

Section 2:
----------

Draft mentions that one could place a MAP in the access router:

    For these reasons a new Mobile IPv6 node, called the Mobility Anchor
    Point is used and can be located at any level in a hierarchical
    network of routers, including the Access Router (AR). Unlike Foreign
    Agents in IPv4, a MAP is not required on each subnet.

When would this even make sense? In other words, this is advocating a
foreign agent for MIPv6, something which is in contradiction with the last
sentence in the above paragraph. Not sure this configuration of a MAP in
the access link should be mentioned. Just because it's possible doesn't
mean it deserves any serious consideration. And if it does, then please
explain why it actually makes sense. I'd rather the draft say that, though
possible, this is discouraged (unless it is actually good for something).

Security Considerations Section:
--------------------------------

This section doesn't quite nail the full
mechanism down.  Nevertheless, it assumes that IKE will be used,
although there are issues with it actually working fine (like
using the RCoA as the identity in Phase 2, even though this
configuration would be harder to achieve than currently in
MIPv6 in which the well-known and somewhat static home address allows
its use as phase 2 identity. I don't think this will be directly applicable to
securing a MAP in which the RCoA will not have anything permanent
with regards to any given MN in particular.  I'm not advocating
solving the full problem, just softening the language a bit ("it could work
like this...").

-gabriel

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Nov 2003 12:57:28 -0800

I'd say it is FFS. 

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Nov 2003 13:03:22 -0800

Gab,

> solving the full problem, just softening the language a bit ("it could
work

I think this could work with IKEv2, but it would require an effort on the
order of that for draft-ietf-mobileip-mipv6-ha-ipsec-06.txt to specify it
and therefore should be left to MOBOPTS.

As the draft currently stands, however, I agree that it would essentially
require a statically configured RCoA; otherwise, the RCoA couldn't be used
as the IKE Phase 2 identity. Something else, like the DNS name, could be,
but the effect of that on movement would be a question, since the DNS name
won't be included in the handover signaling.

My $0.02 bhat.

            jak

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Nov 2003 22:05:13 +0100

> won't be included in the handover signaling.

Yes, which is why the somewhat authoritative tone makes me uncomfortable
and am recommending softening to not imply that this current
text is sufficient or even along the right lines.

-gabriel