Subject: [Mip4] Comments on draft-ietf-dhc-mipadvert-opt-01.txt

From: "Espen Klovning" <[email-masked]>
Date: Mon, 1 Dec 2003 19:00:16 -0500

Another late response to the poll on the list:

As Sami pointed out, the mechanism discussed in this draft has merit in more complicated foreign agent scenarios. I support such a mechanism.

Apart from all the other comments I have seen regarding this draft, I am still left with a few questions/comments. Any clarification will be appreciated.

1) I agree with Sami that a duplication of the existing agent advertisement format is not necessarily a good thing. Mostly because ICMP advertisements include more information than just the Mobility Agent Advertisment Extension, e.g. MAC addresses, ICMP Code fields, Prefix Length. The current extension is a good starting point though.

2) How is the MN supposed to use this mechanism? As far as I can tell, it is not mentioned at all. It might be intentional for all I know. So, should the MN:

A) Use the DHCP Mobility Agent Announcement directly without soliciting for an agent.
B) Solicit for agents but only accept the one(s) indicated in the Mobility Agent Announcement when the DHCP operation is completed.

There seems to be some issues with both approaches when the FA is not co-located but a separate physical entity.
Will the authentication implied by the draft still be useful? How will the MN get the necessary MAC address? Will the MN know whether the FA performs generic routing services or not? 

regards
espen 
Espen Klovning
Birdstep Technology ASA

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 2 Dec 2003 18:25:14 +0100

Hi Espen,

	Thanks for the response. Some replies inline:

Monday  1 December 2003, Espen wrote:
> As Sami pointed out, the mechanism discussed in this draft has merit
> in more complicated foreign agent scenarios. I support such a
> mechanism.
> 
> Apart from all the other comments I have seen regarding this draft, I
> am still left with a few questions/comments. Any clarification will be
> appreciated.
> 
> 1) I agree with Sami that a duplication of the existing agent
> advertisement format is not necessarily a good thing. Mostly because
> ICMP advertisements include more information than just the Mobility
> Agent Advertisment Extension, e.g. MAC addresses, ICMP Code fields,
> Prefix Length. The current extension is a good starting point though.

Ok. This seems to parallel some comments received earlier; I'll propose
some new text to make it possible to indicate fields as inactive.

> 2) How is the MN supposed to use this mechanism? As far as I can tell,
> it is not mentioned at all. It might be intentional for all I know.
> So, should the MN:
> 
> A) Use the DHCP Mobility Agent Announcement directly without
> soliciting for an agent. B) Solicit for agents but only accept the
> one(s) indicated in the Mobility Agent Announcement when the DHCP
> operation is completed.

Not describing this was intentional; it would really be up to vendors and
deployers. But the most straightforward way would be for a mobile arriving
at for instance a WiFi hotspot to acquire a dhcp address and solicit for
FAs in parallel. To differentiate between possible services, the FAs would
be announced only through DHCP, not by responding to router solicitations;
this way the FA and service level offered could be dependent on the NAI
provided by the MN. 

> There seems to be some issues with both approaches when the FA is not
> co-located but a separate physical entity. Will the authentication
> implied by the draft still be useful? How will the MN get the
> necessary MAC address? Will the MN know whether the FA performs
> generic routing services or not? 

As for the authentication, this will be as feasible or not as the
corresponding key distribution problem, I guess.

Given the IP address, the MN should be able to ARP for the MAC address.
That's at least the way I thought about it.

To know what node(s) provides generic routing services, you'd need to
provide the router(s) by DHCP, too, using the router option.

I guess all of this should go into the updated draft :-)

	Regards,
		Henrik