Re: way forward for the mipshop-mos-dhcp document

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: way forward for the mipshop-mos-dhcp document

Jari Arkko-2
FYI. We are talking about this in the DHC WG list.


Jari Arkko wrote:

> Hi all,
> There's a new version. This version completely removes the problems we
> had with the variable encoding.
> The version does keep the ability to provide both addresses and FQDNs
> for the mobility servers, however, using separate options. I
> personally think this issue was far less pressing than the above one;
> if servers can't deal with the encoding that's a serious deployment
> barrier. If there's multiple formats to deliver information, that is
> an extra implementation burden and a potential interoperability issue
> for nodes that choose to disobey the RFC and not implement both.
> However, folks who want to deploy this could overcome these easily. As
> a result, I'm fine with the document moving forward as it is. However,
> the two WGs need to be OK with them as well, and when we talked about
> this in DHC there were concerns about providing both addresses and
> FQDNs. Can we try to close that issue and move on?
> In my mind the question is whether the two formats are justified. I
> have been thinking about this today and I can see an excellent
> argument for why FQDNs need to be supported. There are some, but not
> quite as convincing arguments for why addresses need to be supported.
> The FQDNs need to be supported because DHCP simply delivers
> information about the server, but has no understanding of further
> details. For instance, 802.21 mobility servers may operate using
> multiple transport protocols (UDP, TCP, maybe SCTP). There are SRV
> record mechanisms in place to discover what transport protocols are
> available and at which port they run on. However, the transport
> protocol information is not carried in DHCP (nor would it make sense
> to do so). And it does not help if the DHCP server resolves some of
> these queries, because IMHO it would not make sense for the DHCP
> server to be aware of all the details of client capabilities. As a
> result, it seems that if we want to enable dynamic negotiation of
> transport protocols or ports, you have to support FQDNs.
> The arguments for the pure address delivery are that (1) its the
> common way to deliver information in DHCP, so it could be supported as
> a "base" mechanism for networks that do not need any SRV mechanisms
> and (2) there may be networks that do not have DNS names for all
> entities.
> I personally think these reasons are sufficient to let the documents
> move forward (or to be more exact, insufficient for us to block the
> 802.21 folks from introducing additional complexity if they really
> insist on it). I do acknowledge that the arguments for pure address
> delivery are on the weak side. But what does the DHC WG think? Is the
> above analysis correct? Are there other means to do this that I missed?
> Jari

Mipshop mailing list
[hidden email]