Subject: Re: [Ietf-krb-wg] [dhcwg] WG LastCall: draft-sakane-dhc-dhcpv6-kdc-option-08

From: Shoichi Sakane <[email-masked]>
Date: Thu, 02 Sep 2010 11:49:09 +0900

Hi Bernie and all,

> The main reason we don't generally use DHCPv6 to configure IPv4
> information is because the client would not be able to use the IPv4
> address if just doing DHCPv6 ... hence, we believe that DHCPv6 should
> deal with IPv6 issues and DHCPv4 should deal with IPv4 addresses. So, I
> would recommend removing this from the SUB_OPTION_KDC and just fixing
> this to be an IPv6 address.
>
> Now, there may be times where it is appropriate to include IPv4
> information (such as for configuring tunneling or transition
> mechanisms).

Yes, the guys who suggested it, including Jeff also had concern about the
transition.  If there is no explicit negative effect, DHCPv6 should provide
kinds of IPv4 information.  This discussion should have to be dealt with
at the dhc-wg.

> A minor comment, which you may fully chose to ignore, but it seems to me
> that having a DEFAULT_REALM_NAME suboption (in addition to the
> REALM_NAME) would make a lot more sense than the complicated flags
> encoding. How likely is it you'll have other bits?
>
> The simpler you keep (sub)options, the easier they are for all to
> implement.

Thanks for the suggestion.  Yes, you are correct.  I am rebuilding the
options rather using sub-options.  That was suggested by Ted too.

Since my situation was changed in last JUne, sorry for my delayed response.
Now, I am starting this work.  I am trying to submit new draft by Sep 9th.

Shoichi Sakane

> - Bernie
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ted Lemon
> Sent: Saturday, August 14, 2010 11:03 AM
> To: Jeffrey Hutzelman
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dhcwg] [Ietf-krb-wg] WG LastCall:
> draft-sakane-dhc-dhcpv6-kdc-option-08
>
> On Aug 13, 2010, at 7:25 PM, Jeffrey Hutzelman wrote:
>> In the meantime, I'd like to hear comments from participants in either
>
>> working group on the question of including IPv4 addresses of KDC's in
> this
>> option, given that virtually all KDC's deployed today operate on IPv4,
> but
>> DHCPv6 does not normally support transport of IPv4 addresses in
> options.
>
> Ordinarily, the way we deal with this is to distribute the IPv4
> addresses using DHCPv4, and the IPv6 addresses using DHCPv6.   I've been
> out of the discussion too long to remember why this option was rejected,
> though.
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> ietf-krb-wg mailing list
> [email-masked]
> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Sep 2010 23:06:39 -0400

> kinds of IPv4 information.  This discussion should have to be dealt with

We've had this discussion.   The consensus was (and as far as I know remains) that IPv4 stacks are configured with DHCPv4, and IPv6 stacks are configured with DHCPv6.   It sounds good on paper to just do DHCPv6, but in practice, there is no scenario where you are doing DHCPv6, and also doing IPv4, but not doing DHCPv4.   So sending IPv4 options in DHCPv6 is redundant.   And in the long run it's harmful, since if we add IPv4 options to the DHCPv6 protocol now, we are stuck with them forever.

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 02 Sep 2010 17:05:01 +0900

Hi Ted,

On 09/02/10 12:06, Ted Lemon wrote:
> We've had this discussion.   The consensus was (and as far as I know
> remains) that IPv4 stacks are configured with DHCPv4, and IPv6 stacks
> are configured with DHCPv6.   It sounds good on paper to just do DHCPv6,
> but in practice, there is no scenario where you are doing DHCPv6, and
> also doing IPv4, but not doing DHCPv4.   So sending IPv4 options in
> DHCPv6 is redundant.   And in the long run it's harmful, since if we
> add IPv4 options to the DHCPv6 protocol now, we are stuck with them
> forever.

The problem is that a most deployed KDC daemon can handle only
IPv4 messages even though the PC has a dual-stack.   When a network
is operated by both IPv4 and IPv6, and a node is joining the network,
but the IPv4 address of the node is pre-configured somehow, the node
needs to know an IPv4 address of the KDC in order to communicate with
the daemon.  I am thinking the option should be added into DHCPv4 in
this case for simplicity in terms of implementing.

Well, could you explain bit precisely why it's harmful.  I would
like to convince myself.

Shoichi Sakane

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Sep 2010 10:47:59 -0400

On Sep 2, 2010, at 4:05 AM, Shoichi Sakane wrote:
> When a network
> the daemon.

I am having trouble imagining a scenario where you are hard-wiring an IPv4 address but using DHCPv6 for autoconf.   But if you were to do that, why not use DHCPv4 DHCPINFORM to get the KDC address for IPv4?

> I am thinking the option should be added into DHCPv4 in

Yes, I agree.

> Well, could you explain bit precisely why it's harmful.  I would

More complexity in the protocol.   More choices as to where a particular piece of configuration information comes from.   More potential for ambiguity.   More to get wrong, basically.

---

From: Shoichi Sakane <[email-masked]>
Date: Mon, 06 Sep 2010 12:23:45 +0900

Hi Ted,

On 09/02/10 23:47, Ted Lemon wrote:
>>> And in the long run it's harmful, since if we add IPv4 options
>>> to the DHCPv6 protocol now, we are stuck with them forever.
> More complexity in the protocol. More choices as to where a
> particular piece of configuration information comes from.
> More potential for ambiguity. More to get wrong, basically.

The first and the third are about a documenting issue.
In terms of the operator and the implementation of the server,
the second one is enough for me to understand the reason.

In terms of the client implementation and the transition phase,
if DHCPv6 protocol was able to provide configuration about IPv4 address,
a client would not need to have the DHCPv4 protocol and the parser.
It could save the resouce of a client.  However, in the long run,
I agree with you.  The waste parser routine is harmful.

Thanks, I am convinced.

Shoichi Sakane

P.S.
I apologize that I accidentally removed the dhcwg ML address.
Discussion was kept in the krb-wg ML.  Please find them if interested.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Sep 2010 16:03:48 -0400

The new draft looks fine.   I assume you are only sending on IP address for each KDC because you don't think it's useful to send more than one, not because you feel constrained by the DHCP protocol to only send one.

---

From: Shoichi Sakane <[email-masked]>
Date: Fri, 01 Oct 2010 08:40:02 +0900

Hi,

On 9/11/10 5:03 AM, Ted Lemon wrote:
> The new draft looks fine.   I assume you are only sending on IP address
> for each KDC because you don't think it's useful to send more than one,
> not because you feel constrained by the DHCP protocol to only send one.

Good point.  It needs inputs from the krb-wg.  Yes, I assumed that a client
basically only needs an IP address of each KDC.  However, the protocol could
inform some IP addresses to a clientby sending multiple KDC options.

All, you can find the new draft in the following URL:
   http://www.ietf.org/internet-drafts/draft-sakane-dhc-dhcpv6-kdc-option-09.txt

Any comment would be appreciated.

Thanks,

Shoichi