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

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 13 Aug 2010 19:25:19 -0400

--On Sunday, June 06, 2010 10:28:43 PM -0400 Jeffrey Hutzelman 
<[email-masked]> wrote:

> --On Tuesday, April 06, 2010 08:10:00 AM -0400 Jeffrey Hutzelman
> <[email-masked]> wrote:
>
>>> 1-2: prividing an IPv4 address. section 2.2 (KDC Sub-Option)
>>>
>>>  Jeff>
>>>    > It is not recommended to provide an IPv4 address.
>>>
>>>    Since most Kerberos deployments are currently IPv4-only, I'm not
>>>    convinced this advice is appropriate.  If we believe as a WG that
>>>    this is appropriate, then the phrase "not recommended" should be
>>>    elevated to RFC2119 requirements language (i.e. uppercase), and
>>>    this requirement should be stated separately, rather than as an
>>>    aside to the description of the sub-option length.
>>>
>>>  Shoichi>
>>>    If my understanding is correct, it was the consensus of the krb-wg
>>>    meeting in Stockholm.
>>
>> I will have to look into this.
>
> My reading of the krb-wg minutes from IETF75 shows some support for the
> notion that it should be possible to provide both IPv4 and IPv6
> addresses, but none for the idea that providing an IPv4 address be NOT
> RECOMMENDED.
>
> However, I'm not sure how to reconcile this with Ted's comments about
> lack of support in DHCPv6 for sending IPv4 addresses at all.  This issue
> seems like a showstopper; we need to reach some sort of solution that
> everyone can accept.
>
>
> If you believe you have resolved most of the other issues raised during
> WGLC, please do submit another version of the draft.  Please make sure
> that the issues raised in my original review have been addressed, with
> the following exceptions:
>
>
> - My comments about initial values for sub-option codes no longer apply,
>   in light of the subsequent discussion about eliminating sub-options
>   in favor of using multiple option codes.
>
> - My comments about language describing the use of the Option Request
>   Option no longer apply, in light of Ted's comment (with which I agree)
>   about removing language specifying how ORO works.
>
> - I saw no response to my comments regarding the MUST in section 3.1,
>   in which I suggested removing a fairly large amount of text.  You should
>   leave this unchanged for now; I would like to see some comments from
>   other WG members on this topic.
>
> - I suggested that Section 4 is unnecessary, but again, so no comments
>   from the rest of the WG.  Please leave this alone, at least for now.

I've seen no movement on this.  Please prepare and submit an updated draft, 
reflecting issues from my review (other than the ones mentioned above) as 
well as other comments received during WGLC.

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.

Of course, I'd also like to hear comments particularly from krb-wg 
participants on my suggestion to drop a large part of section 3.1 and all 
of section 4.  If I don't see any comments, I'll assume there is no support 
for those proposals, and the relevant text will stay in the document.

-- Jeff
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Aug 2010 11:02:37 -0400

> 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.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 14 Aug 2010 13:00:13 -0500

I've skimmed this draft quickly ...

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).

---

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.

- 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

> 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