Subject: [dhcwg] Re: [Mip4] draft-ietf-dhc-mipadvert-opt-01.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 25 Nov 2003 11:40:37 -0500

Here is my review of this document. Note that I'm crossposting because
some of my comments are more DHCP-ish, while others are MIP4-ish.

Thomas

>    The Mobility Agent Information field shall NOT be terminated with a
>    255 sub-option.  The length N of the DHCP Mobility Agent Information

Why is this here? There is presumably no "255 sub-option" defined,
since this document definess all the suboptions that are applicable to
this option. Or am I just confused?

>    tuples.  Since at least one sub-option must be defined, the minimum
>    Mobility Agent Information length is two (2).  The length N of the

s/must be defined/must be included in the option/

>    value field.  A sub-option length may be zero.  The sub-options need
>    not appear in sub-option code order.

Would it be appropriate to go further and say:

      The sub-options need not appear in any particular order.

(Just asking, I don't have a strong opinion, other than if ordering is
important, now is the time to make the rules clear.)

>    The Network Access Identifier sub-option of the Mobility Agent
>    Information Option MAY be used by the DHCP client to provide
>    identifying information to the DHCP server, as part of the
>    DHCPDISCOVER message.  The server may then use this information in
>    selecting mobility agent announcement parameters for the client.

Can this sub-option only be provide in the DISCOVER, or can it also
appear in the REQUEST? (I would assume both, i.e., I think clients can
provide options in the REQUEST normally)

>    Option code
>       DHCP_MIP_OPTION (to be assigned by IANA)
> 
>    Length
>       Length in bytes of this option, not including the Option code and
>       Length bytes.

Not sure why you include this here (section 3.3.) the picture shows
only a suboption. Shouldn't the description just include the
sub-option fields? (This is also for consistency, since the other
suboption doesn't seem to include the code/length of DHC option
itself).

>       The address trough which the Mobile Node may reach the announced

s/trough/through/

>    Sequence Number
>       The count of Mobility Agent DHCP announcements made since the DHCP
>       server was initialized (RFC 3220, Section 2.3.2 [5]).

This is copied from the MIP advertisement. But does it make sense
here? Isn't this for replay protection (or something?)? Not sure the
same rational applies here. Also, this is a potentially significant
new requirement on the DCHP server. I'm not aware of any other option
that requires this sort of state me maintained.

Also, what does it mean in the context of DHC, where the server may be
talking to multiple  different clients... Is this a per-client count,
or a total count?

>    B
>       Busy.  The foreign agent will not accept registrations from
>       additional mobile nodes.

Also copied from the MIP message. But the DHC server generally won't
be able to set this bit sensibly as I would assume only very loose
syncronization between the DHC server and specific mobility agents.

> 6. IANA Considerations
> 
>    The value for the DHCP_MIP_OPTION code must be assigned from the
>    numbering space defined for public DHCP Options in RFC 2939 [10].

Create a new IANA registry for future subtypes?

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Nov 2003 11:03:36 -0600

Thomas, FYI, I think that the extra wording about ordering and end 
options is there because implementors sometimes (often enough that it's 
been an observed problem) fail to read the documents carefully, and 
this creates interoperability problems, so repeating things that are 
already obvious if one has carefully read, e.g., RFC2132, is actually 
constructive.   We have, for example, encountered DHCP client 
implementations that blow up if you send the options in an unexpected 
order, or expect options to be padded so that multibyte values are 
appropriately aligned for picky architectures.   Usually these 
implementations either don't last, or get fixed, but IMHO it's worth 
adding a little extra verbiage to try to nip these errors in the bud.

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 25 Nov 2003 18:23:39 +0100

Thank you, Thomas.

	Comments below.  /Henrik

> this option. Or am I just confused?

I doubt the latter :-)  I included this here as there exists an
255 end option (not sub-option) which seems to have prompted the
same clarifying (or confusing!) text in some other documents defining
suboptions. It doesn't seem needed, but maybe there is history
lurking here?

> s/must be defined/must be included in the option/

Yes.

>       The sub-options need not appear in any particular order.

Yes. And (as urged by other people on the dhcwg list) I'll change the
zero length part to require a flag instead of using the option presence
itself as a flag.

> provide options in the REQUEST normally)

Both make sense to me. Will rectify.

> suboption doesn't seem to include the code/length of DHC option

Yes. should be sub-option, not option.

> >       The address trough which the Mobile Node may reach the announced

Yes.

> that requires this sort of state me maintained.

There are instances where the use of this field would make sense, 
mostly to signal a re-boot of a box with co-located dhcp server and
fa. But in most cases, it should be possible to signal that this
field should be ignored. My thought is to add a bit field whereby
this and any other selected field may be marked "to be ignored".

> talking to multiple  different clients... Is this a per-client count,

Total count, not per client.

> syncronization between the DHC server and specific mobility agents.

Agree; basically the same comment applies here as above for the
sequence number.

> Create a new IANA registry for future subtypes?

Yes.

---

From: Alpesh <[email-masked]>
Date: Tue, 25 Nov 2003 11:47:09 -0800

Pete, Henrik -

I have a few comments/questions regarding the draft --

1. Looks like the option (along with the sub-options) can be used in 
both discover/request
    and reply (DHCP) messages. Can you add text to clarify this?

2. How do you suggest the DHC server use the NAI? Is any form of 
interpretation
    recommended?

3. What happens when the Mobile is from a different domain and so the 
DHCP server
     cannot understand the realm in the NAI. (Related to #2 above).

4. Would it be helpful to tie the NAI with the ci_addr field? This way, 
when some other
     client makes a DHCP request using the ci_addr field (and not the 
mobility option with
     NAI suboption), DHC server can do some co-relation? I say this 
because I think ci_addr
     is a well understood/implemented option.

5. RFC 3118 (I haven't read it in detail) specifies mechanism to 
authenticate DHC messages.
    THe security section mentions that this is one advantage of using 
agent advertisements
    from DHC as opposed to FA as from 3344. My question is, what if the 
MN is roaming
    in the foreign domain? How are keys distributed to authenticate the 
signature (authenticator
    field)? Isn't that the reason the FA advertisements are not 
authenticated?

6. Since FA/DHC servers are supposed to be autonomous entities (running 
on same or
     different boxes), how does the DHC server keep track of the 
availability/loading
     conditions at the FA (especially if they are separate boxes)?

7. Also, as Thomas suggested, I would like to have text clarifying that 
further sub-options
     may be added.

Thanks
Alpesh

Pete McCann wrote:

>Hi,
>
>The MIP4 workgroup has received a query from the DHC workgroup regarding
>the draft draft-ietf-dhc-mipadvert-opt-01.txt. The viewpoint of the MIP4
>working group is needed in order to advance or retire this document.
>Responses are needed before 1700 EST on Thursday November 27th.
>
>The WG last call on this document was announced before the Minneapolis
>meeting, on both the DHC list and the MIP4 list. There were responses
>on the DHC list, but none on the MIP4 list. We therefore again ask for
>input from the MIP4 workgroup.
>
>Please respond to this query.  If you support acceptance of the document
>without change, respond with a simple acknowledgment, so that support
>for the document can be assessed. Please respond at the latest before
>1700 EST on Thursday November 27th.
>
>draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called the
>Mobility Agent Option, and two sub-options of the Mobility Agent Option: the
>Network Access Identifier Sub-Option, which provides
>identifying information about a DHCP client to the DHCP server and the
>Mobility Agent Announcement sub-option, which announces the address of one
>or more mobility agents available to a host. This draft is available as
>http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt
>
>
>-Pete
>
>
>  
>