I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines DHCP options to discover mobility servers. I have some general questions and some security specific questions plus a few editorial nits. General: a) You define "Mobility Services" but in the definition of "Mobility Server" you refer to "Mobility Support Services". Are the terms "Mobility Services" and "Mobility Support Services" the same? If yes, choose one and stick to it. If not, a definition is likely needed to explain the difference. b) The document spells out that multiple IP addresses in a DHCP MoS option are processed in order of preference. Should the document also state explicitly how multiple DHCP MoS options are to be processed? One might assume that multiple DHCP MoS options are processed in decreasing order of preference as well but I think this is not spelled out. c) I am not a DHCP / DHCPv6 person and thus this question might be just show my ignorance - but anyway: Can the new options be used in mixed IPv4/IPv6 environments? Can I obtain IPv4 addresses of Mobility Servers from a DHCPv6 server? Can I obtain IPv6 addresses of Mobility Servers from a DHCP server? Security: d) I think the security considerations should mention that the resolution of DNS names itself is a risk unless DNS security is applied, perhaps with an explicit pointer to the security considerations in . e) The text recommends the use of the DHCP authentication option [RFC3118] or the use of link layer security. And then the third paragraphs starts with "This will also protect the denial of service attacks to DHCP servers". There are three questions here: - What is "This" refering to? Do both the DHCP authentication option and link layer security protect against DoS attacks? Or does "This" refer to link layer security only? - The security services provided by RFC3118 and link layer security are likely not the same. (The RFC3118 option provides me with trust that I am talking to the right server while link layer security likely only provides me trust that I talked to some server on the right link layer endpoint. - I find link layer security somewhat opaque since I am not sure what precisely this stands for. I understand that it will be not a good idea to list link layer specific things here but perhaps spelling out which security services a working link layer security technology must provide would help. My recommendation is to rewrite the security considerations so that the text discusses in one paragraph the usage of RFC3118 and then in a subsequent paragraph the usage of link layer security mechanisms. Right now, the discussion jumps between these two options making it more difficult for me to understand the statements being made. Editorial: - Items (1) and (2) should be moved from the abstract to the end of the introduction. This way, the acronyms are introduced before they are used. - p1: 'a list IP' -> 'a list of IP' - P2: 'an mobile' -> 'a mobile' - p2: 'set of different services' -> 'set of services' - p11: '(as defined in [RFC2131]' -> '(as defined in [RFC2131])' - p12: '(as defined in [RFC2131]' -> '(as defined in [RFC2131])' /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 < http://www.jacobs-university.de/ >