[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] Review of draft-ietf-mipshop-mos-dhcp-options-05.txt
Here's my comments after m a quick look at this work, without fully
understanding what it is used for:
- Abstract
This document defines a number of Dynamic Host Configuration
Protocol (DHCP-for-IPv4 and DHCP-for-IPv6) options that contain a
Don't we usually just say "DHCPv4 and DHCPv6"? MINOR.
- 2. DHCPv4 Option for MoS Discovery
This section describes the MoS option for DHCPv4.
The MoS option begins with a option code followed by a length and
sub-options. The value of the length octet does not include itself
or the option code. The option layout is depicted below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option 1 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option n |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
OPTION-IPv4-MoS (TBD) - 2 bytes
Length
2 bytes
Sub-options
A series of DHCPv4 sub-options.
DHCPv4 options have a *1-octet* option code and length, not a 2-octet.
- Later in this section, the sub-opt format is also wrong (1-octet
length is used by DHCPv4).
- Later in this section, while the presently defined suboptions (1-7)
use this format with the "enc" byte, perhaps future sub-options will not
need this? So, I'd suggest they clearly state that suboptions 1-7 use
this format [future suboptions may or may not].
- And, in this section, note that the maximum length of a DNS label is
254 bytes because of the 1 enc byte and sub-options can only be up to
255 bytes long (regardless of whether RFC3396 is used).
- And, perhaps a simplication if they just need the existing suboptions
would be to define the option as follows:
Option Code (1 octet) - TBD
Option Length (1 octet)
Service Name flags (1 octet) - Name 1
Bit 0 - IS service name
Bit 1 - ES service name
Bit 2 - CS service name
Bit 3-7 - MBZ
Encoding flag (1 octet)
Data length (1 octet)
Data (depending on encoding)
Service Name flags (1 octet) - Name 2
Bit 0 - IS service name
Bit 1 - ES service name
Bit 2 - CS service name
Bit 3-7 - MBZ
Encoding flag (1 octet)
Data length (1 octet)
Data (depending on encoding)
...
Note that the service name/encoding/data length/data can appear multiple
times to allow names for different services to be communicated. If this
is not necessary then the "data length" field is not needed. (If it is
needed, the data length field is required because one can't have
multiple instances of a DHCPv4 option -- see RFC 3396.)
- 2.1 Domain Name List:
They state that DNS wire encoding is to be used by never state whether
compression is or is not allowed. Perhaps it would be better from them
to change the "Section 3.1 of [RFC1035]" reference to "Section 8 of
[RFC3315]" as that states that compression is NOT used.
- 3.1 IPv6 MoS Identifier Option
This option is included in the Information-request message and used
Why only in Information-Request? What about Solicit and
Request/Renew/Rebind?
Note also that this means that a server must have very special
processing capabilities for this new feature. It may be just simpler to
drop this option and place the OPTION-IPv6-MoSINF in the ORO. The server
can then include all instances of the configured OPTION-IPv6-MoSINF
options.
In the DHCPv4 case, no option was sent in the client request to request
specific values, so why is this needed in DHCPv6 (as it isn't needed in
DHCPv4)?
- Section 3.2
For DHCPv6, I'd use a similar option as in the DHCPv4 case above but
there's no need for the data-length because each INSTANCE of the option
can define one set of services. So, the DHCPv6 option is:
Option Code (2 octets) - TBD (OPTION-IPv6-MoSINF)
Option Length (2 octets)
Service Name flags (1 octet)
Bit 0 - IS service name
Bit 1 - ES service name
Bit 2 - CS service name
Bit 3-7 - MBZ
Encoding flag (1 octet)
Data (depending on encoding)
Note: The "service name flags" could be an enumeration as they have it.
But it seems a bit map would be simpler?
That's at least some comments from a quick look at this work, without
fully understanding what it is used for.
- Bernie
-----Original Message-----
From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf
Of John Jason Brzozowski
Sent: Friday, October 03, 2008 9:21 AM
To: dhc WG
Cc: dhc Chairs; Stefano Faccin; Vijay Devarapalli
Subject: [dhcwg] Review of draft-ietf-mipshop-mos-dhcp-options-05.txt
Folks,
The MIPSHOP WG is working on extensions for discovering IEEE 802.21 MIH
(Media Independent Handovers) severs. The draft at the URL below defines
DHCP options for discovering these mobility servers.
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mos-dhcp-options-
05.t
xt
The MIPSHOP WG has requested a review of this draft by the dhc WG.
Please
review this draft and forward comments the dhc WG mailing list and the
authors of the draft.
Thanks,
Ralph and John
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg