Subject: [dhcwg] re: comments on draft-yan-dhc-dhcpv6-opt-dnszone-02.txt

From: "CTO YAN Renxiang" <[email-masked]>
Date: Thu, 10 Mar 2005 09:46:45 +0800

> Hello,
> 
> I've read the draft, but I simply cannot be sure whether I can support
> this document as a wg item.
> 
> My first question is whether it's typical for the "subscriber" to use
> the ISP's (sub) domain (suffix) for its internal host names.  This
> would make it hard to change providers (they'd rename host names as
> well as renumber addresses), so don't they rather want to use an
> independent domain space?  Perhaps I'm just unfamiliar with this area,
> so this is not an objection to the proposal; rather it's just a
> question.

This option just provides a method to transfer the domain suffix from DHCPv6 server
to DHCPv6 client. The word "provider" is used as an example to illustrate the 
applicability, you certainly can use an independent domain space, but typically, to reduce
management cost, the allocation of this indenpendent domain space is performed 
by the network service provider. 

> 
> Also, I cannot be sure how an end host using stateless address
> autoconfiguration can update its host name using this mechanism (e.g.,
> how can the node know the appropriate "suffix"?).  I hope this draft
> will provide a bit more details on this.
> 

This document does not address this issue, the host's address can be configured
using DHCPv6 or stateless autoconfiguration. The FQDN option provide a method 
to update domain name for the host configured using DHCPv6. The domain name 
update mechnism for the node whose address is configured using stateless 
autoconfiguration remains an ongoing issue, you can refer to another draft in:
http://www.ietf.org/internet-drafts/draft-yan-ipv6-ra-dns-00.txt

> I also understand most of Section 2.1:
> 
>    In stateful DHCPv6, the zone suffix option MUST only appear in 
>    IA_PD-options field of IA_PD option (see [3]) and apply to all 
>    prefixes for that binding.  One IA_PD-options field MUST 
> include none
>    or only one zone suffix option.
> 
> What does "stateful DHCPv6" mean in this context?  Does this specify
> address allocation (at end nodes) by DHCPv6?  Or does this mean prefix
> delegation?

It means "prefix delegation" using DHCPv6. Such kind of usage has been discussed
in the DHC mailing list before.

The term "Stateful DHCPv6" is compared with "stateless DHCPv6", they are 
specified respectively in RFC3315 and RFC3736.

> 
> Similarly,
> 
>    In stateless DHCPv6, the zone suffix option can appear in the 
>    client's message options field in the transaction.
> 
> I'm not sure what "stateless DHCPv6" specifies here.  I also don't
> understand what are "the client's message options".
>

It means it will be used as an options field in the message sent by server to client.
Comparing with the usage in stateful DHCPv6, it doesn't need to be placed in the options
field (suboption) of other options.

> 
> Here are miscellaneous editorial comments I happen to notice:
> 
The typo errors will be corrected in ver03. Thank you.

> - In abstract
> 
>    This document specifies a new DHCPv6 (DHCP for IPv6) 
> option which is 
>    passed from an DHCPv6 server to an DHCPv6 client to specify the 
>    zone suffix name used to construct and perform domain name update.
> 
>    => s/an DHCPv6/a DHCPv6/
> 
> - I cannot parse the second paragraph of Section 3.0:
> 
>    The zone suffix name can then be used to construct can 
> update domain
>    name for the hosts in subscriber network, by an embedded DHCPv6
>    server in CPE or by other means of DNS update mechanism 
> for stateless
>    IPv6 configuration.
> 
>  I suspect there's a grammatical error here.
> 
> - In the last paragraph of Section 3.0,
> 
>    [...]
>    in which an unique zone suffix name prefix, called "home name", are
>    negotiated between user and ISP when subscribing. For example, 
>    "user1.example.com" and "user2.example.com". 
> 
>   => s/are negotiated/is negotiated/
>   => s/an unique/a unique/
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, 
> Toshiba Corp.
> 					[email-masked]
> 

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 10 Mar 2005 13:29:32 +0900

>>>>> On Thu, 10 Mar 2005 09:46:45 +0800, 
>>>>> "CTO YAN Renxiang" <[email-masked]> said:

> by the network service provider. 

Thanks for the explanation, but this does not really address my
concern.  What I wanted to see is an explanation on how this is
realistic in the actual operational usage, rather than "this could
work in theory this way".  As you seemed to indicate, providing an
independent name space from the upstream ISP does not seem feasible to
me.

>> I also understand most of Section 2.1:

(Oops, sorry, I actually meant "I also don't understand" here, BTW)

> http://www.ietf.org/internet-drafts/draft-yan-ipv6-ra-dns-00.txt

??? I'm now totally confused...According to this explanation,

- for a host using DHCPv6 for address configuration, we use the FQDN
  option.
- a host using stateless address autoconfiguration is not in the scope
  of the zone suffix option.

then why do we need the new option in the first place?

Please be more specific on the expected usage.

> specified respectively in RFC3315 and RFC3736.

Of course I know those wording and RFCs.  But in my understanding,
stateful / stateless are typically used in the context of address
configuration.  In the context of prefix delegation, there's no
"stateless" counterpart.  That's why I was confused.

But I'm afraid it doesn't make sense to continue disucssing the
wording issue unless the expected usage is clarified (see above).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]